How to Discover the Complexity of Software Project

Introduction

Anyone who has led a software project knows how challenging it can be to transform an idea into a functioning product. This complexity is amplified when faced with the task of understanding existing code or introducing a new, intricate functionality.

In the arsenal of software development processes, there are many techniques available.

The ones that I find to be the most valuable and practical to consider when balancing budget, business and project value, and the necessary knowledge transfer between the client and the business are:

  • UML diagrams such as data flows,
  • Detailed use case scenarios,
  • C4 diagrams
  • Event Storming (a method created by Alberto Brandolini)

In fact, when it comes to the order, I would start by first outlining rough use case scenarios, and then as soon as possible, initiate an Event Storming session.

I would like you to be aware of the existence of this technique, not with the intention of fully explaining it, but to indicate when it’s beneficial to use it.

Although it is possible to conduct an Event Storming session using computer tools, the best results are achieved during a real meeting at a large wall. Participants attach colorful sticky notes, allowing to see the entire picture of the system, rather than just fragments visible on a computer screen. Direct interaction and real-time communication make the process more fluid and effective.

When to use Event Storming?

Event Storming is a domain modeling technique that focuses on identifying events within a system. It is particularly worth reaching for during:

  • the start of a new project at the very beginning,
  • the introduction of a new, complex functionality into an existing project,
  • attempts to take over and modify legacy code, in order to understand how the system works and possibly remodel it to improve cohesion in business logic.

This technique consists of several key phases, such as: BigPicture ( Wild Exploration, Enforce The Timeline, Reverse Narrative, Actors & Systems), Process Level, and Design Level.

Engagement is the key to a successful Event Storming session. It should resemble a brainstorming session where everyone contributes ideas and data. As subsequent sessions are conducted, experience grows. However, it is beneficial if an experienced project manager or someone with a wealth of experience in software development is involved from the initial sessions. This person can act as a facilitator, guiding the process and steering discussions by asking questions.

During an Event Storming session, various roles are established such as:

  • Facilitator: Guides the discussions and keeps the session on track.
  • Domain Experts: Provide insights into the specific areas being discussed.
  • Developers: Offer technical perspectives on the feasibility of the discussed concepts.
  • Users: Offer insights into user needs and expectations.

However, it’s crucial to acknowledge that there are situations where Event Storming might not be the best fit. For instance, it may not be as effective for small-scale projects with simple logic or for projects where real-time collaboration is not feasible. Additionally, if the stakeholders or team members are not fully engaged in the process, the outcomes might be less beneficial.

Conclusion

Event Storming is an extremely valuable tool that allows me to deeply understand business logic and its boundaries. It is an excellent starting point for identifying key components of a system’s architecture. However, it is not a tool for designing a full architecture. After completing an Event Storming session, it is worthwhile to complement its results with more formal design tools, such as UML diagrams – sequence diagrams or class diagrams, which help in further precise modeling of the system.