In Why We Should Build Software Like We Build Houses, the author Leslie Lamport makes the case for creating detailed specifications for building software following the model of how an architect’s blueprints are used for building a house.
Lamport goes on to suggest: “Can this be why houses seldom collapse and programs often crash?” Seldom, perhaps, but with especially catastrophic consequences, such as the 68,000+ people killed in the recent 2008 Sichuan earthquake. Most of the deaths were due to the collapse of poorly designed or constructed houses.
However, as bad as that is, the 1556 Shaanix earthquake killed more than 800,000 people, which at the time was at least 0.25% of the world’s total population. The equivalent death toll today: 17.5 million.
It’s hard to imagine an earthquake today that would kill 17.5 million people. And that’s largely because we know more about how to design and build houses for events such as earthquakes than we did in 1556. The point of this is to illustrate that methods for building houses are far more mature than for building software. Humans have been building houses at least since the last Ice Age, software, for barely 50 years. That’s a reason why we don’t build software like we build houses – it’s simply so new we are still in the early days of figuring out what works.
Knowing how to build houses or software to be robust during failure conditions is part of the solution. Another part is that architects and contractors have a mature form for communication: the blueprint. Blueprints are such complete and specific documents that a contractor could be reasonably expected to complete a house even without continued input from the architect. Architects who create blueprints have extensive knowledge about materials, joints, weatherproofing, building codes, fasteners, almost every detail. Most people responsible for software products rarely create software specifications to the same level of detail as an architect’s blueprint. Whatever the equivalent is, it clearly needs to be more developed that what we normally think of as a software “spec”.
Indeed, the software industry in large part has pointedly turned its back on well-developed construction paradigms with trends like Extreme Programming, Agile, Lean, and Minimally Viable Product. Many of these techniques involve iteration, quick results, and fast prototyping. I see these reactions not as embracing a superior method, but instead reflecting creative searching within a new technology. Eventually, I think we will develop more formal methods for planning and building software, technology for software blueprints will emerge, and highly technical product architects will effectively span the divide between vision and code.
The relative newness of consumer and even enterprise software means we have still have workarounds and a measure of tolerance for computer failures. However, even only a few decades into the computer era, we are increasing our expectations around continuous availability of our systems and disaster recovery/data safety for our data.
This will likely drive new baselines for reliability and availability of software, and with it, the need to more fully visualize the system we are trying to build. At WANdisco, we are seeing urgent requirements emerge around software development tools, Git and Subversion, and also as Hadoop and big data analysis transitions from promising curiosity to ubiquitous backbone technology. Non-Stop Data™, indeed.
We don’t build software like we build houses because we don’t know enough yet about building software, and to a lesser extent because we aren’t completely dependent on software yet. As the field matures, Lamport’s recommendation may yet become standard practice.