Software Development is Not Construction

When talking about software development, it is customary to compare it with construction. We put the case like this:

"First you must decide what to build. Talk with the client and gather their requirements. After that, create an architecture and a design which acts as the blueprint or specification of the system to be. For this phase, you have an architect. Then you start constructing the system. The programmers then build it. Once they are done, the system is complete".

This construction metaphor sounds great, but there is a huge problem: It is wrong, completely wrong. It gives the impression that software should be created like we build houses. Nothing could be further from the truth. In fact, I see nothing in the above comparison that resembles programming. I have never seen houses created with a text editor, nor have I seen software created by digging holes in the ground and filling them with concrete and iron bars. They are simply two different things, with nothing in common. It makes no sense whatsoever to keep using this comparison.

The construction metaphor is the main cause for lots of problems we have in the software industry today. It has permeated how we think and how we work. Clients believe it, organisations believe it and many programmers believe it. It is the reason why consultants are allowed to waste many years on a client project before it fails. Even the words we use for writing software echos this sentiment -- architecture, specification, construction, building, phase, completion. A carpenter builds, a programmer writes. We are not in the business of building software, we write software. 

A Problem with Houses

When construction begins, requirements are set in stone. In construction, clients are forced to make expensive decisions early on when they have little knowledge what they really want. Only when the building is completed and you have lived in it for real can you appreciate (or not) your early design decisions. This is the reality of construction; you are constrained by the laws of physics, regulations, material etc and there is not much to do about it. Or at least it is very costly to fix. The upside with houses is that they are generally easy to understand and decisions are mostly correct.

The difference between houses and software is that software is, well, soft-ware. Software is free from physical constraints, which means we can create software in whatever form we like. The options are endless and that makes it much harder than deciding than how many rooms a house should have. 

With software, we have a unique opportunity to write just a small part of the system, evaluate it and adjust the next step based on that. That is just not possible in construction.

So why do we insist on intentionally constraining software development to the same limitations that apply to construction? It makes no sense to me. After all, programs are plain text. Change it when it turns out to be wrong. Evolve it. There is no physical concrete-and-iron structure holding us back.

In short, software allows us to delay expensive decisions until we have as much information as possible to make them as good as possible. That amazing thing is what we are giving up when subscribing to the construction metaphor. The loss is obvious, but what do we gain from that and what do our clients gain from that? Nothing, except it fits our mental model of how physical things are constructed.

Software Evolves

Software is never finished. It evolves (or dies). Pick any program you use today and consider how it has evolved over time. Your Windows system, your browser or your favorite IDE. They are hardly the same today as they were when they first released. The code, design and everything else has changed over time. Software is never completed, releases are simply arbitrary points in time when someone decided that now is a good time to make it available.

This is even more obvious with agile software which are released weekly or even daily. Why make such a big fuss over the first release as compared to the second or the 23rd? Why spend so much time with architecture and architects when the only thing we can know for certain is that it will change or, more probably, be replaced when we learn more about how to use it? Especially when software can easily be changed and houses cannot.