Monday, May 29, 2017

Construction engineering is NOT a good metaphor for software

Metaphors are a great tool to explain other people complicated concepts. Often, they help us to drive interesting conversations and expand the boundaries of the knowledge we have by borrowing ideas from other fields.

In the Software industry, it seems like one of these metaphors is particularly strong, the one that tries to explain software as building houses. We even use it at our universities to introduce the topic to newcomers.

In my opinion, this metaphor is not only wrong but also very dangerous. Thinking about our profession as construction engineering makes us think that:
  • There is a clear construction phase separated from a maintenance phase.
  • Maintenance is cheaper and has a longer duration than the construction phase.
  • Once we have enough documentation and schemas, we can just follow the plan.
  • There is no incremental value. The construction goes from "not done" to "done".
Even if you think it might help in some way, please reconsider.

It does generate more problems and confusion than not using it at all.

In Software, features are done when the last customer stops using it. Maintenance is way more expensive than bootstrapping the project. There is no separation between construction and maintenance.

Software is Agile, Lean, it does change and evolve continuously. Software requires constant adaptation. Agile becoming mainstream in software projects is not a coincidence but the revelation on how Software works nowadays.

Software is not delivered in in CDs anymore. Systems are developed, grown and run as biological organisms evolving all the time.

It is true there are different phases within the roadmap of digital products and that there are different trade-offs to consider, but each of these phases are determined by evolutionary steps. Change is the only constant.

We can do better, we should strive for a better metaphor to help us being more effective explaining what do we do and how Software works.

Perhaps, a comparison with medicine might be more accurate

  • It is a knowledge-based profession
  • No one wants medicine or surgery if it can be avoided
  • Clean code is like eating healthy or making exercise
  • Pairing and code review is the second opinion
  • Making changes to the system running is like making surgery with the patient alive

Medicine might not be a great alternative but it's better than the original construction engineering proposition. Construction engineering will make us think the construction phase requires heavy investment when in reality the cost will always be in evolving 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.


  • Some projects have very well defined phases, and that's okey. Hopefully, we'll have less and less of these projects each year.
  • Many thanks to @keyvanakbary for his help with the English writing.

Sunday, May 14, 2017

Interesting technical Talks/Podcasts (May 2017)

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

Thursday, May 11, 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.


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.