How I learned to do Big Design Up Front in 2 days of Event Storming
The combination of Incremental Design and Event Storming is a better alternative to Big Design Up Front. It’s faster, safer and creates natural buy-in.
ℹ️ NOTE: An updated version of this post has been published on the Event Storming Journal blog
In my previous post, I explained how I tried to apply Big Design Up Front at my first job. Long story short, I did not manage very well…
This is the second post in a series about how to use Event Storming to kick start architecture on good tracks. If you haven’t yet, I recommend you to start reading from the beginning.
Incremental architecture to the rescue
Here I was: I had tried to apply Big Design Up Front to keep the software tidy. Unfortunately, I was still facing regression at every new features. I started to look for ways to better design software. That’s how I discovered the refactoring book:
In it, I read about eXtreme Programming, which got me to read the XP book:
I got sold on XP. I jumped in. Within a few month I was unit testing a lot. I had swapped Big Design Up Front for incremental design. The idea is to start and keep the simple code. (Remember: Simple is not Easy).
Just get started, and refactor a lot as you go.
I have practiced incremental design since then. It’s better than Big Design Up Front in almost all aspects.
- It’s fast to get started. This alone removes a lot of the risks:
- Of demotivating people
- Of building a deprecated design
- Of falling into analysis paralysis
- It remains open to change, because the code remains simple
- It avoids over-engineering, because we only code what’s needed
Here is the main lesson I get by looking back all these years. We cannot achieve a sustainable pace without incremental design.
💡 We cannot achieve a sustainable pace without incremental design!
The main problem of incremental design
Without a clear design, you’ll waste your time refactoring over and over. That’s true.
In practice, this is not a big issue if you are working alone. Once you’ve spent enough time at a problem, you’ll form a mental design target. From then on, you’ll always refactor in this direction.
The problem is trickier for teams. A few years ago, I joined a team as technical lead. Because of turnover, I became the only experienced programmer in a team of juniors. We were doing incremental design and refactoring. Unsurprisingly, the team turned to me to provide them an architecture vision. Having this shared vision helped everyone in the team to know how to refactor the code at any moment. It avoided both conflicting and dead-end refactoring.
💡 Having a shared vision helped everyone in the team to know how to refactor the code at any moment.
As the team members grew in experience though, they started to suggest more design ideas. It became more and more difficult to agree on a vision. This translated directly in more time wasted in conflicting refactoring initiatives.
The Event Storming compromise
I did not know how to solve this problem until I discovered Event Storming.
I first heard about it through the internet. The first time I had the chance to practice it was when a team at work asked for help to organize one. They wanted to on-board newcomers. I then went through a few practice sessions. Finally, I had the chance to attend a workshop with Alberto Brandolini at a conference. That’s when I’d finish my rookie training at Event Storming. The main feedback I got through all these sessions was “Massive knowledge sharing”.
During his workshop, Alberto also said we could use it to identify the bounded contexts of the domain. This statement sparkled my interest. Could this provide the collaborative architecture vision that incremental design lacks?
After reading through the beta release of Alberto’s book and more experimenting, I can say it is. Whenever we start something new involving architecture:
- A new product, project or startup
- Almost any kind of legacy refactoring effort. For example:
- To modularize your architecture to scale to more teams
- To break a monolith into micro-services to support a continuous-delivery SaaS business model
- To rewrite a poor-quality part of the system, which generates excessive support costs
Event storming let us draft a good enough functional architecture vision. (Context Map for Domain Driven Design aficionados). Even better: it lets us do this collaboratively, in a couple of days! It’s not bloated like the BDUF, but still provides a Rough Design Up Front. It complements incremental design to get something even better.
Next posts
This was the second post in a series about how to use Event Storming to kick start architecture on good tracks. In next post, I’ll explain how to run a Big Picture Event Storming. Later, I’ll go over how to draft a functional architecture from there.
Leave a comment