Big design up front
 | This article needs additional citations for verification. (October 2009) |
Big Design Up Front (BDUF) is a 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.
Arguments for
Proponents of waterfall model argue that time spent in designing is a worthwhile investment, with the hope that less time and effort will be spent fixing a bug in the early stages of a software product's 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 of the 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, several commentators[2][3][4] have argued that what Joel has called Big Design Up Front doesn't resemble the BDUF criticized by advocates of XP and other agile software development methodologies because he himself says his example was neither recognizably the full program design nor completed entirely upfront: [5]
"This specification is simply a starting point for the design of Aardvark 1.0, not a final blueprint. As we start to build the product, we'll discover a lot of things that won't work exactly as planned. We'll invent new features, we'll change things, we'll refine the wording, etc. We'll try to keep the spec up to date as things change. By no means should you consider this spec to be some kind of holy, cast-in-stone law."
Arguments against
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. For substantial projects, the requirements from users need refinement in light of initial deliverables, and the needs of the business evolve at a pace faster than large projects are completed in - making the Big Design outdated by the time the system is completed.
They also assert that there is an overhead 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 than the cost of fixing then time spent planning is wasted.
Continuous deployment, automatic updates, and related ideas seek to substantially reduce the cost of defects in production so that they become cheaper to fix at run-time than to plan out at the beginning. In reality, run-time fixes are vastly more costly than design fixes, so it is critical to use Agile methods such as frequent demonstrations and user feedback during development to fix issues during the development cycle. Improving software with the benefit of user feedback is generally less expensive than trying to anticipate and document every aspect of a system with BDUF.
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.[citation needed]
Alternatives
An alternative approach is Rough Design Up Front[6][7][8] (RDUF) in which 'sufficient' design is completed up front to provide a framework on which to build in the design detail as the project progresses.
A similar approach has been called Sufficient Design by Joshua Kerievsky:[9]
"I'm saying that we need high design quality for stuff that is critical to our products and less design quality for stuff that isn't critical."
Advocates of Scrum refer to the concept of Emergent Design:[10]
"The difference on a Scrum project is not that intentional design is thrown out, but that it is done (like everything else on a Scrum project) incrementally."
See also
References
- ^ Joel Spolsky (2005-08-17). "The Project Aardvark Spec". Joel on Software. Archived from the original on 12 April 2006. Retrieved 2006-04-26.
- ^ "A 20 page spec for a 3 month project is a great thing! But it's not BDUF, it's SDUF" Rich Rogers[1] Archived 2006-02-09 at the Wayback Machine
- ^ "Unfortunately, looking at his spec., it seems to bear little relation to the type of BDUF that XP (extreme programming) and other agile programmers inveigh against." Curt Sampson[2] Archived 2011-05-18 at the Wayback Machine
- ^ "So, of all the things this spec might be, a big, up-front design document is not one of them." Kevlin Henney[3]
- ^ Joel Spolsky (2005-08-17). "Project Aardvark Functional Specification" (PDF). Joel on Software. Archived from the original (PDF) on 2012-05-09. Retrieved 2012-07-19.
- ^ Täuber, Johannes. "... programming, technical stuff, agility ..." Retrieved 19 July 2012.
- ^ "How do you design complex systems with TDD?".
Start with a rough design idea
- ^ Sedley, Liz. "Rough Upfront Design".
- ^ Kerievsky, Joshua. "Sufficient Design". Industrial Blogic. Retrieved 19 July 2012.
- ^ Cohn, Mike. "Agile Design: Intentional Yet Emergent". Mountain Goat Software Blog. Retrieved 19 July 2012.
