Earlier this year the term Hayim Makabee proposed the term 'Adaptable Design Up Front' as a way of pointing the way forwards between the Scylla of BDUF and the Charybdis of degenerating into a Ball of Mud.
Others have used the term 'Just Enough Design Up Front.' But what counts as just enough?
That's the wrong question. Because 'just enough' is an insight that misdirects you. Design is not a scalar quantity like length. There is no amount of up-front design that is the right amount. The question is, what are the useful bits of design to do up front?
And this is what 'Adaptable Design Up Front' addresses. What you must do up-front is support the change and development to come — usually growth or change in functionality — whilst nailing down the things that ought to be fixed: the invariants which give stability so that developers don't have to re-learn the system from scratch each day they come into work.
So the basic idea is this: you want just the up-front design that helps you to draw lines between things that will change frequently and things that remain stable over time.
So how to do it?
For the 3 minute kick-start, Hayim has an excellent set of slides to get you going. His 'architecture vs interior design' analogy and the idea of applying the open/closed principle at the architecture level hit that 'brilliantly simple' spot that make it all seem obvious in hindsight.
ADUF - Adaptable Design Up Front –Hayim Makabee
For more detail on designing for what changes vs. what stays stable, I seriously recommend Jim Coplien & Gertrud Bjørnvig's under-rated book Lean Architecture: for Agile Software Development which contains decades of hard thought and wisdom. They know the pitfalls on the way first-hand and they can help you navigate them. More important, they show how to prioritise the human factors in your technical architecture. Which, as every architect knows, is what really matters.
Unfortunately there is no one size fits all. BDUF could be the perfect approach in some particular projects, ‘no design up front (NDUF)’ as well. ADUF still has the risk of closing the wrong things and overcomplicating things by providing too many open extension points. Too many projects fail because of this ‘best practice’ thinking.
What every projects needs is a strategy for design: when and how much to design, ways of dealing with unknowns, agreements on when and who reviews the design and the strategy.
Hi Machiel, thanks for dropping by. What would be your example of a project where BDUF is likely to be better than iterative design & development?
I think the basic agile argument is, ‘Nearly all of the time the customer of a large software product doesn’t quite know what they want until they’ve seen something that’s what they want. Therefore it’s better to get started, deliver something and get feedback. Therefore design is best done incrementally.’ I don’t think I’ve yet seen a counter-example first-hand?