“Sure, you’d like to convince all your clients to sit down and really think about it, but you might as well try and convince everyone to stop fighting wars.”
Actually, most of the world has stopped fighting wars. If we could get Richard Cheney, Haliburton and their Texan puppet to stop, we might have nearly 99% of the world’s population adhering to that. Note: This blog software won’t let me put in Richard Cheney’s common name - Dic.
Now, on a more software related note, getting people to think about what they want is sure a heck of a lot easier with analysis/design tools like activity diagrams, use cases and domain models than it is with code. So, if that makes me a BDUF proponent then I guess I am. Most customers do know what they want - where the failing is will usually be in the translation of their business model/processes into requirements. They are not used to thinking in terms of requirements and therefore cannot verify that the requirements say what they want. They are not used to critiquing requirements, therefore they read into them what they want to see. The requirements change when they do realize, based on what they have seen/heard since the initial writing, that what is being built has little to nothing to do with what they want. Sure, they’ll make mistakes too but not as many as development teams will claim. Customers need something closer to their way of thinking, often a business-oriented way of thinking, in order to understand if their requirements are being properly recorded and met. Activity diagrams approximate business flows. Use cases (as per Alistair Cockburn) provide a more storylike approach to telling them what they will get. Domain models tell them what “things” in their business world are going to be available in the eventual software system. Try accomplishing that with code.
As for delaying decisions to the last responsible moment … … I went to a talk given by Mary Poppendieck on this topic and I chatted with her somewhat afterward. My interpretation of what she was saying is that delaying a decision to the last possible moment is NOT procrastination or laziness. Actually, I might argue it is hard work. You must not simply wash your hands of the decision until it is forced upon you, driving down the road to deadline oblivious to that decision. Rather you need to be constantly tracking and assessing the impact of the various decision options. How else would you know when the responsible moment has been reached or breached? You must consider in your design (and if you simply cannot think unless the debugger is doing it for you, then in your code too) so that whichever of the candidate decisions (or even new candidates that arise) eventually gets chosen due to cost/benefit, feature completeness or whatever metric, your system can rapidly (dare I say agilely) advance towards effecting that decision.
Alas, I suspect that as with XP, Agile, Test Driven Development and all the others, developers will bastardize what Mary is saying into “we don’t have to think about that because we are delaying that decision to the last responsible moment”. This will, of course, like all the other valid methodologies destroyed by the extreme interpretation by hackers, leave Mary’s idea as just more roadkill along the path to more decades of inferior, expensive and failed software projects.