Why Software Development Is Not Like Construction Building: Two Worlds Apart (and one thing in common)

Why would a couple of pundits in a very popular #AI podcast claim that software development is like building a house?

In the world of software development, you often hear comparisons to various domains to help non-technical individuals understand the process. One of the most common metaphors used is "software development is like construction building" in some way or another. While this comparison may seem appealing on the surface, it falls short in capturing the essence of software development. If you are familiar with both software development and building structures, you know it is outright wrong. In reality, software development and construction building are two vastly different realms, each with its unique characteristics, challenges, and approaches. In this article, I'll delve into why these two worlds are indeed orthogonal, highlighting the fundamental differences that set them apart, but most importantly why it matters.

Tangibility vs. Abstraction

Construction building is tangible; you can see, touch, and physically interact with the end product. Whether it's a house, a bridge, or a skyscraper, the results of construction projects are evident to anyone. In contrast, software development deals with abstract concepts and intangible creations. Lines of code and algorithms are the building blocks of software, making it challenging for non-technical individuals to grasp the intricacies of the final product. This is critical: the architectural decisions made for a physical structure are strategic. Changing them is expensive, if possible, so you need a lot of these decisions taken upfront. In software, we tend to defer technical details as much as possible. We care about the interfaces that are the contracts of interaction. People laugh or wonder when I say that "cloud is a technical detail" - especially cloud people. But it is so; there is no reason that you build your software system with cloud in mind. If you do take this decision, it will drive some downstream technical decisions but it is not necessary to begin your design with the cloud hypothesis.

Rigidity vs. Flexibility

Construction projects are inherently rigid. Once a building is constructed, it's difficult and costly to make substantial changes. Software, on the other hand, thrives on flexibility. Developers can easily adapt, modify, and enhance software applications. Software is soft and malleable. You can change it. You should be able to change it, even midway during construction. When you build a ship (I am a naval architect originally) you cannot work iteratively so easily. Ships tend to be binary: either you have one or you don't. Software on the other hand, is flexible in the amount of value it delivers, delivery and even construction. You can start your software project by implementing a Proof of Concept (PoC) or a thin slice, then either grow or destroy it and start anew with lots of new knowledge, deliver an MVP with limited but useful functionality, give it to customers and learn from them, pivot on your decisions, change your requirements and so on.

Design and Planning

In construction, a comprehensive blueprint is created before the building process begins. The plan is meticulously followed to ensure the final product matches the design. You roughly know the resources you are going to need and the time it will take. If you need to accelerate your project, you might add more people or money or both. But you cannot change the scope.

In software development, initial planning and design are crucial, but the iterative and agile nature of development allows for adjustments and improvements as the project progresses. In Agile development, you fix your resources and time and can allow for variation of the scope. As discussed earlier, you cannot deliver a partially completed ship, but you can deliver a feature set that is good enough to allow customers to do their work. That doesn't mean that any feature set is good enough but software flexibility allows for adjustments in the scope. On the other hand, throwing money to the project does not necessarily mean that you can accelerate it: you might have the opposite result. There's a principle that applies here:

You cannot deliver a baby in one month from 9 pregnant women...

Originality

Once you build a number of tankers or skyscrapers, the challenges reduce. More or less, they are all the same. Software on the other hand, is to a large extent unique. The next software project is, quite likely, a journey on uncharted territory. People may have experience on something similar, but software you build once and sell many times. You cannot do that with ships. So software poses always new challenges. It requires prototyping at different levels. It will almost certainly pose new challenges in algorithms, integration, deployment, security. You can hire the same developers to do the same thing and the result in terms of code will be different.

Lifespan

Buildings have a long lifespan, often measured in decades or even centuries. Software products, however, have a much shorter lifespan. In the fast-paced tech industry, software can become obsolete in a matter of years or even months. This difference in lifespan affects the approach to maintenance, updates, and long-term sustainability. Technology is changing fast and one needs to be up to date with the current trends. apart from AI, the major innovations around software development in the last 10-20 years were around deployment, namely cloud and mobile devices. These drove a lot of other innovations of course and a software developer cannot just ignore these, in most cases.

Why does it matter?

While the metaphor "software development is like construction building" is often used to simplify and communicate the development process, it oversimplifies the unique challenges, characteristics, and nature of each field. In reality, software development and construction building are quite orthogonal to each other. The tangible vs. abstract, rigidity vs. flexibility, design and planning, cost and time estimates, and lifespan distinctions highlight the fundamental differences between the two worlds.

These differences matter a lot and often cause misunderstanding between development teams and other stakeholders, so it is important to understand why you cannot and you don't even want to treat a software project like a skyscraper, or a major refactoring like a kitchen remodeling. I think it will make everyone's job much easier if these differences are clear.

I promised a similarity: whatever you do, on average, both software projects and construction projects are running off budget and time. Why? Because engineering and architecture is not treated holistically.