BDUF stands for Big Design Up Front and is used to indicate that the whole design solution is done before execution. This is typical of traditional models of software development, where there is an explicit phase of Analysis prior to the implementation phase. So in short, BDUF is the art of doing things that shouldn’t be done.
In the ’90s, the successive failures of BDUF projects encouraged the creation of new development methods such as Scrum. With the emergence of the Agile Movement in 2001, criticisms of this great anticipation in planning became more robust.
The Chaos Report of 2002 was followed by the realization that, even in projects considered successful (time frame and costs carried out according to planning), the percentage of useful items was extremely low.
Examples of BDUFness:
In product development:
- 6 months of Design Thinking.
- User story mapping with dozens of stories.
- Design of all system screens before implementation.
In software development:
- The creation of an entire API of services before considering their application.
- Thinking through the best possible architecture, in some absurd cases even forgetting to keep an eye on the product’s objective.
- Creating parameters for all variables, before a demand even exists.
In other areas:
- Marketing BDUFers are those who carry out big campaign launches simultaneously on several media, without doing any user acceptance trials. In more modern marketing, advertising is more and more directed at being a continued action with digital media usage.
- UX (User eXperience) is also an activity which, if you don’t watch out, can easily become BDUF. For instance, some companies spend months drawing up all user profiles, considering exceptions and standards which don’t even represent 1% of the interested audience or the product’s value. Nowadays, if Design Thinking lasts six months, then, in the end, you’re just going to have to start over again, because the world will have already changed. We believe in Agile Design Thinking!
BDUF in life:
Sometimes we see people who plan too much or too far in advance with the illusion that they’ll be able to control everything that’s going to happen. For example:
- people who plan every last detail of a vacation, and who become frustrated by the unexpected;
- people who decide that in order to find love they should join a gym for a year, then spend another year learning to dance and only then start going out to clubs.
How not to be a BDUFer:
- Avoid “Seeing as how…” You know how it goes: seeing as how we’re creating this new field in the data table, might as well add a few other possible fields. Seeing as how we’re going to change this code, might as well do a complete refactoring. Every time someone says “seeing as how”, make sure it’s not a sign of BDUFness.
- Planning respecting the horizon analogy.
- Slicing. Faced with a big problem, instead of breaking it down into technical pieces, we should slice. In other words, divide something which needs doing into smaller pieces which still contain a value. As well as avoiding BDUF, there are endless advantages to slicing, for example, a heightened focus on where the value actually is.
- Build incremental solutions and emergent architectures.
Try it out in practice!
- The culture of experimentation is one of the changes of greatest impact when companies begin to implement Agile Methods. When it’s understood that we’re always experimenting, there’s less pressure to find a perfect solution at the outset of an initiative.
- “No reuse without use”. People often try to justify BDUF to avoid “reworking” something in the future. But then anticipate a job before there’s even any benefit to what’ll being carried out. Having good architecture is important, but it needs to be lean, focused on the next value deliveries, on what we call emergent architecture. We recommend the practice of refactoring to increase the reuse of code, but first one must focus on usage.
- 1,2,N. The 1,2, N standard refers to solving the problem to one solution, then to a second, and then to N. This topic deserves a post of its own.