Why we absolutely should never build software like we build houses

! Warning: this post hasn't been updated in over three years and so may contain out of date information.

Image of a madly designed houseA few days ago, I read something truly depressing. It was a piece written by Leslie Lamport, “a computer scientist … member of the National Academy of Engineering and the National Academy of Sciences. [with a] Ph.D. and M.A. in mathematics from Brandeis University and B.S. from MIT [and he] works at Microsoft Research.” Yet for all these grandiose accolades, he demonstrates a depressingly clueless understanding of his subject matter: software. In his article, he argues that we should build software like houses. In this article, I’ll detail why attempting to create applications in the same way as building houses is a really bad idea, which held back software development for decades. Further, the reality is that these days, architects are more likely to design houses using techniques pioneered by the latest software development practices.

Let’s consider what is involved in building a house. In simplistic terms, a client pays an architect to create a set of plans. Regulators will check those plans to make sure they meet local legal requirements. The client will check the plans, and hopefully understand them enough to agree to them being what they wanted. Then in come the builders, who dig and lay foundations, build walls, one brick at a time etc. Then it’s the turn of electricians, plasterers, tilers, plumbers, carpenters, decorators etc to do their own little bits. All the way through, regulators will appear, demand changes to what’s being built and the client will realise what they asked for (or what they are getting) wasn’t quite what they wanted. Each regulator or client change then costs extra time and money. Finally, the building is complete and the architect updates his plans to what was created. And all of this will have taken many months.

So let’s imagine we had to develop applications like this. A client approaches a software developer and describes the application they’d like. Now let’s assume the architect’s drawings, calculations and notes, at a readable text size, took up four sheets of A2 in our house example above. This which equates to 16 sheets of A4 (around the same number of sheets of US “letter” sized paper). So for this to be a fair analogy, we will allow the developer 16 sides of A4 to express the entire application design. Even leaving aside the fact that the code is in reality the main part of the design, that’s not a lot of space to express an application design. Especially if screen mock-ups are needed. So let’s be really generous therefore and allow 16 sheets of A4 for the requirements, plus mock-ups and 16 sheets for the code. At a generous 50 lines per sheet, that’s a whole 800 lines of code! So we are clearly dealing with a very simple application.

QA check the design and the client is asked to examine the code and mock-ups, plus the list of requirements, to confirm that’s what they want. Next, weeks are spent formatting a section of disk space (laying the foundations) before the code is handed over to the lexical analyser. This then takes a couple of weeks to create a set of lexicons (the brick walls get built). Next a series of parsers – one for strings (plumbers), one for keywords (electricians), one for numeric constants (plasterers) etc – each get a go at parsing the lexicon set. At each stage, QA stop the entire process for hours at a time to check and change the lexicons as the program slowly comes together. After many months, the program is finally finished, and – if the client is lucky – it’ll meet their (rather simple) desires.

When the likes of Leslie Lamport talk of building software like houses, the above clearly isn’t what he means, and that’s where the real problem lies. Leslie talks of “building software”, not “building applications/programs/libraries”. In the early days of software development, the industry became seriously derailed by misguided engineers misunderstanding what they were dealing with. Used to the ideas of designs being done on paper, they made the mistake of viewing coding, not as designing a program, but as building the source code from a design. Even today, large companies employ folk, commonly called analysts, systems engineers or software architects, who’s job is to come up with a design that poorly trained code monkeys can then build (implement). Of course, these days such companies are fast fading into history and agile practices, code-as-design-documents etc are becoming mainstream. Or so you’d think. Sadly, the crazy old ideas of the past have proven hard to shake off and many – Leslie Lamport included – either have failed to notice, or refuse to accept, that writing code is design. To talk of software development as lacking in design is to show a seriously misguided view of software, but it’s sadly a view that persists even today in the minds of too many.

The comments in Leslie’s article are as depressing as the article itself. Along with the ridiculous suggestion that somehow developers aren’t thinking whilst coding, we get, for example, the suggestion that the most complex software could be compared to the pyramids: ie big, but crude and taking lots of time and effort to build. Traditional engineering used to involve cheap designs and expensive builds. These days, this has changed, for more time is spent designing and less in building physical prototypes and in building over-engineered structures due to the need to avoid failure. Why the change? Simple: it’s because of software. Far from being crude, simple systems, software systems can be created these days that are so complex, they can even model the physical systems of all the other engineering and science disciplines. Complex systems like modern aircraft, mobile computing devices etc just wouldn’t be possible to design without software systems to help model them.

Modern software development couldn’t be more removed from building a house if we tried. We have gone from being seen as cheap labour employed to implement others’ designs, to leading the way in agile, test-first, professionally developed designs that offer rapid customer feedback of the world’s most complex systems and, at the same time, offering reductions in costs to the customer. Yet despite this progress, Leslie Lamport and his ilk show that the software development profession still has a problem. Too often, too many people – writers of software included – seem to remain oblivious of what has happened with advances in ideas and techniques for designing high quality software. They seek, through ignorance, to drive us back to the bad old days of doing software all wrong. Hopefully, this problem is confined to the older generations and this thorn in our side will wither away as those “dinosaurs” of our industry retire. We shouldn’t be complacent though. Whilst we have great tools and methods for designing software better than ever, many developers do not yet use the likes of TDD, design patterns and clean code. We should not just seek to educate those folk in design “best practices” but should guard too against the software dinosaurs, lest they kid younger developers into thinking ideas like “we should build applications like we build houses” are somehow valid ideas in the 21st century…

7 thoughts on “Why we absolutely should never build software like we build houses

  1. “Next, weeks are spent formatting a section of disk space (laying the foundations) …”

    How depressing: their building metaphor is flawed enough that you don’t have to cheat and put absurdities in their mouth.

  2. I’ve learned that there are a lot of problem spaces in programming, and different problem spaces require different solutions.

    I’m guessing your problem space does not intersect Leslie’s.

    To simply derried that paper, however, shows a lot of arrogance on your part. You sited his impressive credentials without giving any consideration to the possibility that somewhere along the way Leslie could have encountered problems you have not.

  3. @Bill,

    I gave serious consideration to such a possibility, as evidenced by the fact that I ploughed my way through the entire article, rather than giving up after the first ridiculous claim. The notion of creating software solutions in the same way we create physical items is nothing new. In fact it dates from the beginning of software engineering. We may a huge mistake in thinking that way. I gave Leslie the benefit of the doubt though due to his credentials. It was a mistake on my part, as despite those credentials, he was talking utter nonsense.

    By the way, suggesting someone is arrogant for questioning the words of an apparent expert is a classic case of “appeal to authority”. The victim of that fallacy seems to be you on this occasion.

  4. wow, I haven’t read a piece promoting these olde worlde views for quite some time, I have found my dinosaur, lets examine the piece:

    But few programmers write even a rough sketch of what their programs will do before they start coding. — poppy cock, if it’s not the simplest of thing to solve most developers worth their salt either write the high level view of the proposed solution or the more talented ones conduct thought experiments on it trying to break their own solution before a single line has been realised.

    Most programmers regard anything that doesn’t generate code to be a waste of time. — horse apples, most programmers who aren’t still clinging onto the waterfall model like Leonardo Dicaprio clinging to the wardrobe as titanic sinks regard the production of code as almost the antithesis of good development, in fact producing less code is generally seen as a good aim.

    Thinking doesn’t generate code, and writing code without thinking is a recipe for bad code. — no thinking doesn’t generate code, but as laid out earlier it provides a sound basis for thought experimentation and mental simulation and stimulation prior to writing, and how dare you suggest that coders don’t think…unless your still labouring under the wholly misguided and antiquated assumption that hoardes of monkeys at keyboards actually write code to fit the designs of a “architect”.

    Oh my god by this point I am starting to think I’ve been sucked into a very clever satirical piece written by a developer deriding ideas of the past pointing out just how silly they are…but no it would seem this guy really believes his own rhetoric.

    I think the article from here on in is a perfect example of the fact that how ever many years experience you have if you’ve not been keeping then the experience counts for squat. The article speaks of ideas that at least 30 years ago were frowned upon and most companies regard as being down right dangerous. Write specs then code then give to customers then fix whatever faults occur is what took many companies to the wall, someone should help the guy catch up with a few decades of agile development techniques.

    As for not questioning the ideas of someone because of their credentials, this is the only way to stagnate progress, ALL ideas should be questioned and if they hold up to scrutiny then they are shown to be good. The ideas of any non-famous person should never be held in lower regard than famous people in their field, imagine where we would be if a certain patent clerk working out of Swizerland hadn’t question the grandfather of physics at the time?

    I am with David Arno on this one, I can’t believe the article hasn’t garnered more ridicule than this, in a word it is poor.

    By the way I have no personal bad feelings about the author I’ve never heard of him before, however I do take pride in my profession and feel a little education is in order.

  5. Reminds me of that quote “If houses were built like software projects, a single woodpecker could destroy civilization”

    But as you say – that is why nowadays the growing trend is to apply TDD to ensure the software is robust, and use BDD and rapidly prototype applications so you don’t spend months creating something the client did not actually want.

    It seems to me this dude probably mainly works for public sector projects where there is not the push nor even the need to be agile and competitive. I have often wondered whether agile applies as effectively to non-commercial type projects.

  6. As usual, taking things literally in absolute terms causes misunderstanding. “If houses were built like software projects, a single woodpecker could destroy civilization” isn’t meant to mean we should design software like we design houses. It’s meant to point out that most software is like a science experiment for the end consumer, with complex dependencies, and unforeseen causes for failure, and usually a very cavalier attitude towards problems.

    The statement merely promotes a logical basis for software that can ensure robustness based on some compatibility with the (virtual, artificial, imaginary) world in which it must live. Software could be more like an appliance, you turn the key and it works. Things like cars handle continuous improvement and upgrades, without creating an environment the end user doesn’t understand or incompatibilities within the environment.

    The amount of flexibility and complexity within the software “problem space” allows for more rapid development, but it comes with it’s own problems, and could remedied with more environmental regulation. It’s often a matter of the economics of infinite multi versioning.

Comments are closed.