Emergent Design

August 28, 2012

One of the most common points of extreme contention I find between Agile and Waterfall practitioners involves a heated debate about the appropriate time in the project’s life cycle to be making important decisions about the software’s architecture. In one corner, we have the Waterfall approach of Big Design Up Front (BDUF), and in the other corner we have the Agile approach of Emergent Design. I’d like to outline some of the key differences between the two design philosophies because I think the right choice becomes obvious when they’re contrasted appropriately.

Big Design Up Front is exactly what it sounds like: a series of protracted deep-dives into a perceived holistic view of the application. I say “perceived holistic view” because this view assumes that the impressions the BAs and the Architects have of the project before it’s been built are all correct and immutable. Of course, the major drawback to BDUF (and Waterfall, in fact) is that this assumption not only tends to be incorrect with extreme consistency, but is also regularly invalidated very early on in the project’s life cycle. This is primarily due to the facts that first, humans are fallible and miss requirements or design accommodations; and second, projects evolve very quickly.

Emergent Design is very much to the contrary of BDUF: it is a series of design decisions made out of necessity, rather than supposition. It is design at the last responsible moment: the moment after information has been collected to give appropriate context to a problem, but before it’s too late to backtrack without reasonably expensive changes. Emergent Design balances strategic design decisions based largely on implicit requirements with tactical design decisions based largely on immediate needs. It assumes refactoring happens every day, and that the optimum design is approached successively, rather than modeled up front.  I know it’s tempting to do BDUF — you think you’ve got it all figured out, and you want to see an intelligent design come to fruition. Trust me on this: resist the urge. You’ll never know less about the optimum design than you do right now.


John is a serial conversationalist who spends entirely too much time engulfed in problem domains he knows nothing about and has no earthly business trying to learn. He can occasionally be found at your local coffee shop writing algorithms and trying to think deep thoughts.