While this blog mostly addresses software testing that is not the only thing I do.
I am also Scrum Master and provide agile coaching. This post is about a topic I have run across particularly in agile environments but is also used in discussions about other development practices.

Why isn’t software development like building a house!?

Building a house starts at the foundation not at the roof!

Houses, bridges and building in general is predictable, why isn’t software building?!

These remarks and similar ones express the discontent some have with software development in general and agile software development in particular. A discontent that I believe arises as a side effect of two agile development basic elements: “transparency” and “prioritization”. Transparency has the effect that a lot of things that usually take place behind the scenes or that are handled implicitly become visible to a wider audience. Prioritization in agile regularly breaks with the seeming simplicity and logical sequentially of traditional software development as it focusses on delivering valuable but partial solutions first rather than complete solutions later. And it does so visibly.

The simplicity of building…

So is building a house really that simple?
Populistic concepts edict that building follows these, or similar, steps:

• Pouring a foundation
• Erecting the walls
• Flooring
• Adding a roof
• Closing up with windows and doors

Occasionally an architect, electricity and plumbing is added but not much more. In any case building is considered fairly simple and straightforward and essentially the question is raised why software development isn’t?

The answer to that question is actually simple.
If software development were only compiling the final build and deploying that to production it would be as simple. But software development is not only creating a build an deploying it and neither is building a house if you look further.

A more realistic view on building a house

Building a house doesn’t start with pouring a foundation, it doesn’t even start with the blueprint the architect makes. It started earlier with the design and production of all the materials the architect and the builder chose for construction of the house. Concrete, bricks, wooden beams, pipes, cables, lighting, etc. did not appear out of thin air and ready for use. All of these materials have undergone their own designing, prototyping, testing, and fabrication process before they could be picked by an architect and used by a builder on site. Let’s take a closer look at bricks to illustrate this.

In the Netherlands and Belgium alone there are over 45 different sizes of bricks, there are many mixtures of ingredients (clay, sand, minerals, water,etc.), colors, and textures. While some of the differences are merely decorative many of them are functional. And that is just the brick itself. Consider also all the possible ways of stacking them and all the kinds of cement that can be used to keep them together that took years and years of practical (live) tests.

So before any first brick is laid not only the architect and builder have chosen which brick to use and how to use it. The manufacturer of the brick has also implemented design specifications, chose a mixture of ingredients, chose a way to manufacture it and had it tested for durability, fire proofing, insulation and structural integrity.

This is so for for most if not all materials used in building. Some of them may be more or less generic but all of them eventually have a specific usage in building a specific house.

Comparing building a house to software development

So how does building house then compare to software development. Well building a house basically can be seen as the sum of all individual material developments integrated into constructing a house. When looking at it in that way it is not very unlike software development of an application. In software development the individual components of the application are developed and eventually integrated into a full application.

Yet in practice building a house is not conceived as similar to software development. And that is not surprising. While in software development components are often developed as part of the same project in which the application is delivered. While in building the individual materials are most likely developed and manufactured separated both in place and time from the actual construction of the building.

Another similarity between building a house and developing software is that, contrary to the simplistic view, both are hardly ever right first time. In fact errors are so common in building that professions and consumer societies exist that are largely based on its shortcomings. Like software development, where there are software testers, auditors etc., building also has its inspectors, overseers etc..

A difference between software development and building a house is the visible duration. While building (and deploying) software can take a few minutes to up to a few days. Building a house takes a few days up to several weeks. On the other of side of the medal preparation of building a house is largely unseen. Which is quite the opposite to developing software. Getting up to a deployable build can last a few days to several months and sometimes up to several years.

Conclusion

I think the continued use of technical references and terminology in software testing spurs the comparison between software development and building. It seems to me that the remarks with which the post started find their basis in a incomplete vision. A vision that is based on contextual experiences. Working in an IT environment lets you see what a struggle software development is. And when your vision of house building comes from an owners perspective you are likely only to take the final construction as reference with all its supposed simplicity.

Even when the development processes leading up to construction is taken into account there still are significant differences in time, space and execution that outweigh the similarities.