Big design up front
Big Design Up Front (BDUF) is a term for any software development approach, in which the program's design is to 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.
Arguments for Big Design Up Front
Proponents of BDUF argue that time spent in planning is a worthwhile investment, and reference numerous studies which have concluded that less time and effort is spent fixing a bug in the early stages of a software products lifecycle than when that same bug is found and must be fixed later. That is, it is much easier to fix a requirements bug in the requirements phase than to fix that same bug in the implementation phase, as to fix a requirements bug in the implementation phase requires scrapping at least some implementation and design work which has already been completed.
Joel Spolsky, a popular online commentator on software development, has argued strongly in favor of Big Design Up Front:[1]
"Many times, thinking things out in advance saved us serious development headaches later on. ... [on making a particular specification change] ... Making this change in the spec took an hour or two. If we had made this change in code, it would have added weeks to the schedule. I can’t tell you how strongly I believe in Big Design Up Front, which the proponents of Extreme Programming consider anathema. I have consistently saved time and made better products by using BDUF and I’m proud to use it, no matter what the XP fanatics claim. They’re just wrong on this point and I can’t be any clearer than that."
However, some argue that what Joel calls Big Design Up Front doesn't resemble the BDUF criticized by advocates of XP and other agile software development methodologies.[2][3][clarification needed]
Arguments against Big Design Up Front
Critics (notably those who practice agile software development) argue that BDUF is poorly adaptable to changing requirements and that BDUF assumes that designers are able to foresee problem areas without extensive prototyping and at least some investment into implementation.
They also assert that there is an Overhead (business) to be balanced between the time spent planning and the time that fixing a defect would actually cost. This is sometimes termed analysis paralysis.
If the cost of planning is greater then the cost of fixing then time spent planning is wasted.
Continuous Deployment, Automatic Updates, Fault Tolerance, Lisp's Read-eval-print loop and related ideas seek to substantially reduce the cost of defects in production so that they become cheaper to fix at run-time then to plan out at the beginning.
Also in most projects there is a significant lack of comprehensive written (or even well known) requirements. So in BDUF a lot of assumptions are made that later prove to be false but are designed and possibly already coded.
See also
References
- ^
Joel Spolsky (2005-08-17). "The Project Aardvark Spec". Joel on Software. Retrieved 2006-04-26.
{{cite web}}: Check date values in:|date=(help) - ^ "A 20 page spec for a 3 month project is a great thing! But it's not BDUF, it's SDUF" Rich Rogers[1]
- ^ "Unfortunately, looking at his spec., it seems to bear little relation to the type of BDUF that XP and other agile programmers inveigh against." Curt Sampson[2]