Construction engineering is NOT a good metaphor for software

Metaphors can be a useful way to explain complex concepts to others. They can stimulate interesting conversations and help us to expand our knowledge by drawing connections with ideas from other fields.

In the software industry, one commonly used metaphor is the idea of building software like building houses. This analogy is often used to introduce the topic to newcomers in universities.

However, in my opinion, this metaphor is not only inaccurate but also potentially harmful. Thinking about our profession as construction engineering leads us to believe that:

• There is a distinct construction phase that is separate from the maintenance phase.
• Maintenance is less expensive and longer lasting than the construction phase.
• With sufficient documentation and schematics, we can simply follow a set plan.
• There is no incremental value; construction progresses from "not done" to "done".

Even if you think this metaphor is helpful, please reconsider it.

Using the metaphor of software development as construction engineering can actually cause more problems and confusion than not using it at all.

In software development, features are considered "done" when the last customer stops using them. Maintenance is typically more expensive than the initial development of a project. There is no clear separation between the construction and maintenance phases in software development.

Software is flexible, dynamic, and constantly evolving. It requires continuous adaptation and is not a one-time construction project. The widespread adoption of agile methodologies in software development is a recognition of this reality.

Software is not delivered on CDs anymore; it is developed, grown, and runs like a living organism that evolves over time.

While it is true that there are different phases in the development of digital products and that different trade-offs must be considered, these phases are determined by evolutionary steps rather than a fixed construction plan. Change is the only constant in software development.

We can do better by seeking a more accurate metaphor for explaining what we do and how the software works. 

One potential comparison might be with the field of medicine:

• It is a knowledge-based profession
• No one wants medicine or surgery if it can be avoided
• Clean code is like eating healthy or exercising
• Pairing and code reviews are like a second opinion
• Making changes to a live system is like performing surgery on a patient while running.

While medicine may not be a perfect alternative, it is a better comparison than the original construction engineering metaphor. Construction engineering leads us to believe that the construction phase requires a significant investment, while in reality, the cost of software development is primarily in the ongoing evolution of the system.

Software is never done, it is always evolving. Software is not done until the last customer logs out and the servers are shut down.

Notes:

• Some projects have very well-defined phases, which is okay. Hopefully, we will have fewer and fewer of these types of projects each year.

Thanks:

Many thanks to @keyvanakbary for the feedback.