Building software is not like building a bridge - except when it is

Software professionals live in a world of analogies. This is because most people don’t understand how software gets built. This isn’t their fault: the number of people who use software greatly exceeds the number of people who build software for a living, so we have to find creative ways of explaining what is going on. Analogies seem to help.

The most pervasive and persistent analogy is that of construction: we talk about building software as if it like building a bridge. We talk of engineering and we talk of architecture. We talk about foundations, and about building blocks. We might even talk about town planning.

It’s easy to understand why we use this analogy: I have used it thousands of times. We live in buildings. Millions of us live in cities, where buildings dominate our environment. We see them being erected and we see them being demolished. For most of us, they are the most visible and famiiar example of something being created. It seems reasonable and helpful to talk to people in terms that they know.

Unfortunately, I think that the construction analogy is often unhelpful. It creates expectations and embeds concepts which cause us problems when it turns out that building software is not like building a bridge.

Let me give three examples.

First, a bridge has a set purpose which is clearly defined up front: convey something (people, vehicles) safely from one place to another. As long as the bridge fulfils this purpose it is a good bridge, for as long as it lasts. By contrast, we may start building software with a a single purpose - but it is extremely unlikely that it will stick only to that purpose through its lifetime. The nature of software means that it can be extended indefinitely to do more work and more interesting things. It is as if a bridge could also become a hospital, or a school, or a spaceport. If we insist on it remaining a bridge, we deny the fundamental flexibility of software.

Second, we can produce a prescriptive design for a bridge before we start building it. We have built bridges before, and we know enough about physics, mechanics and materials to be confident about what we are building. By contrast, although we can define an outline architecture for a software system and make important design choices before we start building, it is inevitable that we will encounter problems that we have never encountered before - as well as unveiling new purposes. For a bridge, building is a process of construction; for software, building is a process of discovery.

Third, a bridge is built once: while bridges require ongoing maintenance and repair, there is only one real construction phase, after which most of the work is done. By contrast, most of the work of development for software happens after the initial release. It is never done until it is decommissioned (and we should remember that most software is never decommissioned).

These examples illustrate the, if we rely too much on the construction analogy, we will give people the impression that, in order to build software well, we must simply figure out its simple and abiding purpose, produce a detailed, exhaustive design, and carry out a single build before handing it over to maintenance. This sounds rather like the heavyweight upfront design methods that were in fashion when I started my career in computing - the same methods that gave us failed projects, monolithic systems and decades worth of unwieldy legacy code.

However, I do think that the construction analogy has some merit: there are some interesting ways in which building software is like building a bridge. Unfortunately, we rarely remember to point them out.

Let’s take three more examples.

First, while exhaustive upfront design is unhelpful for software, there are always some long lasting design choices which determine the nature of what we are building. For a bridge, this might be a choice about materials, or whether we are building a suspension bridge or some other form of bridge. For software, this might be a choice about languages, or frameworks, or architectural principles. As I wrote a couple of weeks ago, we do not always expose these choices to sponsors, or explain their consequences. I think that is a mistake.

Second, like a well-built bridge, which may last decades or even centuries, software has a long useful lifespan. We often talk as if this is not the case. We account for systems as if they have a useful life of years, not decades, and we describe software as ‘legacy’ almost as soon as we have released it. If we recognised that the software we build will be part of our lives and our organisations for a long time, we might plan better for how to keep it in good shape.

Third, for bridges and for software, quality matters. This is obvious for bridges: we entrust them with our lives and safety. It might seem obvious for software, too. After all, we have QA teams and testing tools, change boards and approval processes. Unfortunately, these mechanisms often focus on outward signals of function and performance, not on the properties that matter over time, such as the readability and maintainability of code. If we tested the quality of a bridge in the same way as we test the quality of much of our software, we would drive ten different types of vehicle across it, but never inspect the bolts or the rivets.

These examples show that there is some value in the construction analogy, but we have to dig deep to find it - and are still unlikely to dispel the impression that we are building static structures with fixed functions.?

Ultimately, I think that we would do better by recognising that building software is not like building a bridge, and not much like anything else either. Building software is like . . . building software. We can address the problem that most people don’t understand what that means by explaining it to them. Analogies have a place, but as routes to understanding, not as substitutes for understanding.

(Views in this article are my own.)