[Note: This is an “Executive Summary” I wrote for some co-workers regarding Steve Yegge’s Business Requirements are Bullshit – thanks to Johnny Elbows for reviewing the summary and giving great feedback.]
Big Design Up Front (BDUF) is the methodology in software development that a program’s design should be completed and perfected before that program’s implementation is started. It is often associated with the waterfall model of software development. The argument between the proponents and critics of BDUF has somewhat degenerated into a “holy war”, with most people believing that a compromise between BDUF and the more extreme variants of agile software development is the best solution to most software development problems.
The most important phase of any BDUF project is “requirements gathering” – a project that does not gather the correct requirements will fail, although it will often take an extended amount of time for the effects of failed requirements gathering to actually impact the project. This creates an environment where either a lot of money is spent chasing poor requirements, or projects fail to start because they cannot sufficiently capture the business requirements.
Steve Yegge, a Google Engineer, has written the following article that suggests that this failure is endemic to projects that even need to consider “requirements gathering”. Taking a page from Peter Lynch and Warren Buffet, he suggests that any development project be approached as an investment, and that we should only “invest” in products we would be interested in owning ourselves.
“You can look at any phenomenally successful company,” he suggests, “and it’s pretty obvious that their success was founded on building on something they personally wanted. The extent that any company begins to deviate from this course is the extent to which their ship starts taking on water.” This means that projects which need to go through a “requirements gathering” phase are inherently doomed because “if it’s something you want, then you already know what the requirements are. You don’t need to “gather” them. You think about it all the time. You can list the requirements from memory.”
As we consider taking on projects, I think there is some sound advice contained here about what can make a project fail or succeed, as well as some tips about how simplicity (good) and imagination (bad) can affect the product itself.
