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…