Misadventures with Big Design Up Front

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.

ℹ️ NOTE: An updated version of this post has been published on the Event Storming Journal blog

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:

If it ain’t broken, don’t fix it!

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

In next post, I’ll continue my story and explain how I switched to incremental design. I’ll detail how it fixes almost all of the issues of 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:

1. Misadventures with Big Design Up Front
2. How I learned to do Big Design Up Front in 2 days of Event Storming
3. How to prepare a DDD Big Picture Event Storming workshop
4. How to prepare the room for a DDD Big Picture Event Storming
5. Detailed Agenda of a DDD Big Picture Event Storming - Part 1
6. Detailed Agenda of a DDD Big Picture Event Storming - Part 2
7. Detailed Agenda of a DDD Big Picture Event Storming - Part 3
8. 4 tips that will make your DDD Big Picture Event Storming successful
9. Drafting a Functional Architecture Vision with Event Storming and DDD
10. Build or Buy Software? Identify your core bounded contexts with Event Storming and DDD
11. Ensure core contexts have the upper hand with Event Storming and DDD
12. Focus on the Core with Event Storming and DDD Domain Relationships - 1
13. Focus on the Core with Event Storming and DDD Domain Relationships - 2
14. How to use Event Storming and DDD for Evolutionary Architecture
15. Using Event Storming and DDD to prototype (micro)services and NFRs - 1
16. Using Event Storming and DDD to prototype (micro)services and NFRs - 2
17. Rewrite vs Refactor? Get Insights from Event Storming and DDD
18. Feature Teams vs Component Teams? Decide with Event Storming and DDD
19. How to max out DDD Big Picture Event Storming with other Workshops

Continue Reading…

Thanks to Thomas and Xavier for reviewing this post

Stay up to date with content and upcoming products

I usually write about 15 minutes worth of reading per month. I won't transfer your email. No Spam, unsubscribe whenever you want.

As a gift for subscribing, you'll receive an illustrated mini-ebook "How to start a team coding dojo"!