The management spinoff of the space race and of the dotcom era

ISO9000 was -- to some extent -- the translation of the engineering practices that supported the space program in the 1960s into the world of business: keep your documents controlled, make sure you know that what you are doing is working, and so on.

The equivalent of 1960s space engineering in the modern day is software engineering, and the practices that have been developed by software teams will form the basis of best-practice management in another decade or two's time. 

What practices am I talk about? What is it that software teams do, that is so obviously right that it barely gets mentioned, but is so obviously lacking from non-software business management? (Put another way: non-software business managers drown in email to the point of unproductivity. Why is that? And what does github do which happens to solve these problems?)

• Instructions, procedures, notes, tomes, meeting reports, decision summaries, discussions and so on are living documents. Programs are just an example of these documents. They need version control, and be dynamically generated into their final forms. Here's an article I wrote a few weeks ago about this: http://blog.ifost.org.au/2016/02/draining-meeting-bogs-and-how-not-to_16.html
• Issues, bugs, requests, tasks and so on need to be tracked through a workflow, and assigned to teams and thence down to individuals. (Blog link: http://blog.ifost.org.au/2016/03/draining-meeting-bogs-and-how-not-to.html).
• Operational support teams need to be accessible at short notice, and that often includes specialised development teams who are expensive to interrupt. This dichotomy is what drives teams to adopt text chat where one member of the team has the "disturbed" role to try to answer questions from outside teams. (Blog link: http://blog.ifost.org.au/2016/02/draining-meeting-bogs-and-how-not-to_23.html).
• Outcomes should be expressed as tests that can pass or fail. For programs, this means automated test suites. Outside of software, this is generally "a well-worded contract" but will soon sometimes to mean "contracts encoded in a formal language and attested in the blockchain" or "contract terms that a robot lawyer can read and judge."
• The longer and more continuous and automated the path is from the specification to the finished product the better. Automated builds, automated deploys, coding in domain-specific languages that let ideas be expressed simply -- these are what we use in software. The next decade will see the same ideas expressed in fashion (the dressmakers pattern gets passed to a robot textile workers), in manufacturing (the design gets 3D printed), in law (self-judging contracts) and so on. 

Anything else I should add to this list?

We always talk of the incredible failures of software engineering -- and there are many, and they can be enormous -- but rarely of the incredible progress we have made as well. The progress is invisible and assimilated; the failures become news.

---

I'm hoping to put this (and many other thoughts) together in a book (current working title: "Bimodal, Trimodal, Devops and Tossing it over the Fence: a better practices guide to supporting software") -- sign up for updates about the book here:  http://eepurl.com/bMYBC5

If you like this series -- and care about making organisations run better with better tools -- you'll probably find my automated estimator of effort and duration very interesting.

Greg Baker (gregb@ifost.org.au) is a consultant, author, developer and start-up advisor. His recent projects include a plug-in for Jira Service Desk which lets helpdesk staff tell their users how long a task will take and a wet-weather information system for school sports.