Although a nice idea in theory, Big Design Up Front has many problems that I learned the hard way. We should avoid BDUF most of the time.
At school, I was taught that Big Design Up Front is the only way to go. We even used to write all pseudo code on paper before touching a computer at all!
💡 At school, we were taught to write all pseudo code on paper before touching the keyboard at all!
Old style cowboy design
I entered my first job with a heavy bias towards doing design first. Real-life work surprised me a lot! My colleagues would design on the fly, at the same time they implemented features. Our best design diagrams were rough design sketch on paper napkins. This was almost 20 years ago and the tooling was not that of today. We were learning Version Control, we would not unit test, and a nightly build remained a dream! As a consequence, late design changes were a mess and resulted in an awful lot of regressions.
The general advice around the place was:
I was far from pleased with this technique, and I decided to try something against it. I naively thought that applying what I learned in school would fix the problem. I started to spend more time designing what I wanted to do before “touching the computer”. For more or less a year, I tried. It seemed to work fine at first. Unfortunately, troubles came when I was to add a new feature on top of this initial design. I’d built some flexibility in, but no matter what, never where later needed. I was spending more time to design up front, and still had to hack last minute changes to meet deadlines… This was definitely not a sustainable pace!
In fact, I’d spent a year re-discovering the cons of Big Design Up Front.
Problems of Big Design Up Front
These problems have not disappeared with time. A few months ago, some colleagues asked me to animate architecture meetings. I discovered the same issues again, only worse. This time, it’s not me alone who needs to come with a design, but a group of people who need to agree on architecture. It’s no surprises the project has been struggling to get started.
Here are the typical problems of Big Design Up Front
- Usually involves painful meetings and plenty of document reading
- It can be a long process, especially if many people contribute
- It can lead to a bad design by committee. People end up capitulating to a proposition to stop this painful process
- It always misses things. It’s almost impossible to think of everything on paper. Remember, Powerpoints don’t crash!
- It creates over-engineering. We tend to add future-proof flexibility in the design. We discover that it’s never used when it’s been in the code for years.
- To make things worse, it sometimes takes so much time that it’s deprecated from the beginning.
- Finally, it’s very difficult to get a collective buy-in for it. It’s impossible to get everyone in these BDUF meetings if we want to agree on anything. As a result, the only solution is to mandate the architecture in a top-down manner
You’ve guessed I’m not a big fan of Big Design Up Front…
💡 People capitulate to a design to end this painful BDUF process.
Alternatives to Big Design Up Front
Unfortunately, there is no silver bullet, and incremental design has its own weak points. The lack of a shared vision is the main one. Finally I’ll retrace how I discovered Event Storming, and how it can be used to draft a shared design vision in just a few days.
To be continued
This was the first post of a series about how to use Event Storming to kick start architecture on good tracks. Here are the topics I intend to go through in this series:
- Misadventures with Big Design Up Front
- How I learned to do Big Design Up Front in 2 days of Event Storming
- How to prepare a DDD Big Picture Event Storming workshop
- How to prepare the room for a DDD Big Picture Event Storming
- Detailed Agenda of a DDD Big Picture Event Storming - Part 1
- Detailed Agenda of a DDD Big Picture Event Storming - Part 2
- Detailed Agenda of a DDD Big Picture Event Storming - Part 3
- 4 tips that will make your DDD Big Picture Event Storming successful
- Drafting a Functional Architecture Vision with Event Storming and DDD
- Build or Buy Software? Identify your core functional areas with Event Storming and DDD
- Check that core areas have the upper hand with Event Storming and DDD
- Focus on the Core with Event Storming and DDD Domain Relationships - 1
- Focus on the Core with Event Storming and DDD Domain Relationships - 2
- How to use Event Storming and DDD for Evolutionary Architecture
- Using Event Storming and DDD to prototype (micro)services and NFRs - 1
- Using Event Storming and DDD to prototype (micro)services and NFRs - 2
- Rewrite vs Refactor? Get Insights from Event Storming and DDD
- What teams should we build to support this?
- What else can we do with Event Storming?