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.

Interesting technical Talks/Podcasts (May 2017)

From the tech-related talks I've heard/seen lately, these are the most interesting:

• Must see for anyone interested in our profession and in real sustainable pace:
• Rafael Lopez Diez at The Lead Developer New York 2017 
• #NoEstimates  Allen Holub
• Agile Metrics - Velocity is not the goal Doc Norton

• Other interesting tech-related talks:
• lean customer development with Cindy Alvarez Ep: 512. hanselminutes podcast
• Immutability Changes Everything Pat Helland, "Accountants Don't Use Erasers"
• Demystifying DynamoDB Streams  Akshat Vig and Khawaja Shams
• why software development is an engineering discipline Glenn Vanderburg 
• SE-Radio Episode 284: John Allspaw on System Failures: Preventing, Responding, and Learning From 
• Serverless Architectures and Continuous Delivery Robin Weston
• Hexagonal Architecture meets CQRS Alistair Cockburn. lightning talk with a very good explanation about CQRS and the relation with Hexagonal architecture  (great 5mins)

"Learning & experimenting takes time, and we are always in a time crunch!" -- especially if you're not learning & experimenting ~@tottinge

— Woody Zuill (@WoodyZuill) 12 de mayo de 2017

Focus on verbs, not on names

In my experience, a good strategy to understand deeply a system or a product is:

• Focus the research and conversations on identifying behaviors (actions, verbs, business flows, and events). 
• For these behaviors, we should identify the dependencies, concurrency and parallelism requirements (what depends on what? what actions can happen at the same time? what actions don't depend on any other action? what are the sources/inputs for each action? etc). 

Understanding the concurrent behaviors, allow us to design the system using small pieces that encapsulate state and communicate using messages. A good match for OOP, Actors, Microservices, etc.
Is easy to see that this strategy try to identify the interactions that the users have with our system and the corresponding actions (verbs). It does not focus on the entities used by the system (names).
However, the most used analysis strategy try to identify the entities first, losing all the context about the behavior (messages, flows, rules, etc). This strategy derives, not necessarily, but typically, on anemic and poor models. This is a common approach for people who have misunderstood OOP/OOA.

Conclusion:

I value the process of identifying the entities (names) of a system, but I value more identifying the behaviors (verbs) that define how is used our system and what actions provide to the user.

We should remember that the customer DON'T want software/systems. The software is only a liability, not an asset. The asset is the actions provided to the customer.

Additional notes:

• This strategy can be used at different levels... It helps us to identify bounded contexts, domain events, microservices... And at the low level can also help us to see the concurrent behaviors of each application or service. This allows us to design more reactive and concurrent systems. 
• Focusing on identifying names first, make very hard to fulfill concurrency, parallelism and scalability requirements. 
• In the real world, things happen concurrently. 
• Event storming seems to be a good exercise to identify the domain events, the dependencies, and the behaviors. 
• Any strategy for the analysis should be used continuously. For me, development is always iterative, I don't see it any other way.