There’s always a lot of debate in the various agile groups about what BDUF is, why you should avoid it, when you should avoid it, and why is it bad (or good) for you. I just thought I’d outline my own opinions here.
BDUF, to me, is an attempt to peer into the future. It’s about attempting to predict unknown or uncertain requirements so that you can adjust your design today to accommodate them. However, any time you open or close possibilities, you are peering into the future.
If I say “Oh, I don’t need that” (following the YAGNI credo) then I am making a prediction. Two in fact – I’m predicting that I don’t need it, and I’m predicting that it won’t be too expensive to change later vs change now. In contrast, if I say “I will need that”, I’m making the inverse predictions: I’m predicting I will need it, and I’m predicting it will be expensive (either in time or lost opportunity cost) to do it later vs. doing it now.
BDUF is characterised, to me, by the latter assumption: it will be expensive to do it later, relative to the cost of doing it now. This justifies time and effort _now_ first to determine what _might_ be needed later, and to implement it now rather than later.
Beck, in his XP books, makes the very good point that you can apply various economic models to this problem. Money now typically “costs” more than money later. Therefore implementing now rather than later is more expensive, assuming that the actual monetary costs are the same. (This is true even without inflation; investing the money now in something means you didn’t invest in something else). When you factor in uncertainty, it starts to become obvious that doing it “now” vs. doing it “later” is reasonably clear – do it later, unless it’s going to be a lot more expensive to do later.
Emergent design, on the other hand, seems to be more about “keeping your options open”. Given the choice between two possibilities, pick the one that shuts fewer doors, or that opens the most. You’re not going out of your way to predict the future or to avoid it, but you are trying to deal with certainties.
What is a certainty? An interesting question. Certainties include negatives as well as positives. Consider this problem: You’re writing a program to run a point-of-sale system. You know that “valued customers” get a 10% discount. You know that “non-valued” customers don’t. What you don’t _know_ is if there may be other types of customers.
When you build this system, you can build several different ways of calculating the discount. What is interesting is that most of them are about the same cost – some are less, some are more, but there certainly aren’t order of magnitude differences. So which one do you pick?
Well, a BDUF designer might rush off and spend hours or days determining exactly how many types of customers there are. A “strict YAGNI” developer might write something that coded just for two. However, to my mind, the emergent designer will choose a strategy that allows for _N_ types of customers, perhaps by using a DiscountStrategy obtained from the Customer object.
Why would the emergent designer do this? After all, “you ain’t gonna need it”. True. However, it’s about the same cost, and this approach _doesn’t close any doors_. An approach based on two customer types (or 15, or 1000, or even 1) does.
(A quote I read once said “There are three types of numbers in programming: zero, one, and many”. I can’t remember the source though, and for once, Google is not my friend)
In any case, that in a nutshell is the difference to me between BDUF and emergent design. BDUF spends time and effort _now_ to avoid cost in the future. Emergent design, however, tries to balance between minimising cost _now_ and not closing possibilities for the future. They have essentially opposite base assumptions: the cost of change in the future is either going to be high, or not much more than it is now.
(It’s worth noting that flattening the cost-of-change curve is an explicit goal of virtually all agile methods – the older waterfall methods, by contrast, merely accepted it as something to live with.)
This means that how much you should invest in up-front design depends on the validity of the assumptions. It also means that some up-front design is a good thing: it helps you avoid “evolutionary dead-ends”, and does stop you closing doors you’re are going to re-open soon.
Why am I going over this? Because the other day, one of the people I worked with said that she was told Agile meant you did not planning for the future. She was very relieved when I assured her that, to me at least, Agile means you don’t close down possibilities if it is cheap to keep them open. (Actually, in the particular case involved, it was cheaper to keep it open and generic than it was to close it down!)
Share this:
Software is too expensive to build cheaply.... 