The term Big Design Up Front (BDUF) is used in the Agile community as a derogatory word for the practice of doing all (or most of) the design before starting coding. Agilists agree on the fact that BDUF is not the way to go, but rather to let the design evolve as coding is done.
While evolving a design is good and nice one has to remember that even though big design up front might not be a good idea, all the hard design work still needs to be done at some point. Otherwise you’ll just end up with a big piece of garbage. Therefore, while starting with a story or use case, do take time and think it through and answer a couple of questions for yourself (not an exhaustive list).
- What is the goal of the story?
- In what ways can we solve this?
- How does these solutions fit into the current system?
- What are the pros and cons of these solutions?
- What are the larger problems (if any)?
However, while thinking about all this, don’t try to work all the details out, they will sort themselves out while coding. More importantly, don’t commit to any of the design alternatives you come up with. The important part is thinking the problem through thoroughly. A quote from David Eisenhower sums this up nicely:
In preparing for battle I have always found that plans are useless, but planning is indispensable.
Steve McConnell in the second edition of Code Complete, describes how while he was writing the first edition, design zealots argued for BDUF, and as he was writing the second, some software swamis instead argued for no initial design at all. He says:
In ten years the pendulum has swung from “design everything” to “design nothing”. But the alternative to BDUF isn’t no design up front, it’s a Little Design Up Front (LDUF) or Enough Design Up Front — ENUF.
Another take on this is to make the decision in the Last Responsible Moment, described by Jeremy Miller in one of his articles.
The key is to make decisions as late as you can responsibly wait because that is the point at which you have the most information on which to base the decision. In software design it means you forgo creating generalized solutions or class structures until you know that they’re justified or necessary.
However, one might not use this advice to justify not designing at all. The key here is that you don’t commit to a certain design (i.e. make the decision) until the last possible minute, but you still consider the alternatives — which of course requires you to research and actually think about them!
- 2007-02-08: Original post.
- 2007-07-12: Added the paragraphs on ENUF.
- 2007-07-13: Added the paragraphs on Last Responsible Moment.