Big design up front

Last updated

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.

Contents

Synonyms for big design up front (BDUF) are big modeling up front (BMUF) and big requirements up front (BRUF). These are viewed as anti-patterns within agile software development. [1]

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: [2]

"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 [3] [4] [5] 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: [6]

"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 [7] [8] [9] (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: [10]

"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: [11]

"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

Related Research Articles

The waterfall model is a breakdown of development activities into linear sequential phases, meaning they are passed down onto each other, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks. The approach is typical for certain areas of engineering design. In software development, it tends to be among the less iterative and flexible approaches, as progress flows in largely one direction through the phases of conception, initiation, analysis, design, construction, testing, deployment and maintenance. The waterfall model is the earliest SDLC approach that was used in software development.

A software company is an organisation — owned either by the state or private — established for profit whose primary products are various forms of software, software technology, distribution, and software product development. They make up the software industry.

The rational unified process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003. RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs. RUP is a specific implementation of the Unified Process.

<span class="mw-page-title-main">Systems development life cycle</span> Systems engineering terms

In systems engineering, information systems and software engineering, the systems development life cycle (SDLC), also referred to as the application development life cycle, is a process for planning, creating, testing, and deploying an information system. The SDLC concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both. There are usually six stages in this cycle: requirement analysis, design, development and testing, implementation, documentation, and evaluation.

In software development, agile practices include requirements, discovery and solutions improvement through the collaborative effort of self-organizing and cross-functional teams with their customer(s)/end user(s). Popularized in the 2001 Manifesto for Agile Software Development, these values and principles were derived from, and underpin, a broad range of software development frameworks, including Scrum and Kanban.

<span class="mw-page-title-main">Joel Spolsky</span> American software engineer and writer

Avram Joel Spolsky is a software engineer and writer. He is the author of Joel on Software, a blog on software development, and the creator of the project management software Trello. He was a Program Manager on the Microsoft Excel team between 1991 and 1994. He later founded Fog Creek Software in 2000 and launched the Joel on Software blog. In 2008, he launched the Stack Overflow programmer Q&A site in collaboration with Jeff Atwood. Using the Stack Exchange software product which powers Stack Overflow, the Stack Exchange Network now hosts over 170 Q&A sites.

Capability Maturity Model Integration (CMMI) is a process level improvement training and appraisal program. Administered by the CMMI Institute, a subsidiary of ISACA, it was developed at Carnegie Mellon University (CMU). It is required by many U.S. Government contracts, especially in software development. CMU claims CMMI can be used to guide process improvement across a project, division, or an entire organization. CMMI defines the following maturity levels for processes: Initial, Managed, Defined, Quantitatively Managed, and Optimizing. Version 2.0 was published in 2018. CMMI is registered in the U.S. Patent and Trademark Office by CMU.

In agile principles, timeboxing allocates a maximum unit of time to an activity, called a timebox, within which a planned activity takes place. It is used by agile principles-based project management approaches and for personal time management.

Agile modeling (AM) is a methodology for modeling and documenting software systems based on best practices. It is a collection of values and principles that can be applied on an (agile) software development project. This methodology is more flexible than traditional modeling methods, making it a better fit in a fast-changing environment. It is part of the agile software development tool kit.

Extreme programming (XP) is an agile software development methodology used to implement software systems. This article details the practices used in this methodology. Extreme programming has 12 practices, grouped into four areas, derived from the best practices of software engineering.

<span class="mw-page-title-main">Scrum (software development)</span> Management framework

Scrum is an agile team collaboration framework commonly used in software development and other industries.

An interface control document (ICD) in systems engineering and software engineering, provides a record of all interface information generated for a project. The underlying interface documents provide the details and describe the interface or interfaces between subsystems or to a system or subsystem.

<span class="mw-page-title-main">Functional specification</span>

A functional specification in systems engineering and software development is a document that specifies the functions that a system or component must perform.

Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example is used to capture examples of desired and undesired behavior and guide coding.

A rewrite in computer programming is the act or result of re-implementing a large portion of existing functionality without re-use of its source code. When the rewrite uses no existing code at all, it is common to speak of a rewrite from scratch.

In software engineering, a software development process is a process of planning and managing software development. It typically involves dividing software development work into smaller, parallel, or sequential steps or sub-processes to improve design and/or product management. It is also known as a software development life cycle (SDLC). The methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application.

The INVEST mnemonic for Agile software development projects was created by Bill Wake as a reminder of the characteristics of a good quality Product Backlog Item or PBI for short. Such PBIs may be used in a Scrum backlog, Kanban board or XP project.

A programming team is a team of people who develop or maintain computer software. They may be organised in numerous ways, but the egoless programming team and chief programmer team have been common structures.

<span class="mw-page-title-main">Extreme programming</span> Software development methodology

Extreme programming (XP) is a software development methodology intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent releases in short development cycles, intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted.

Disciplined agile delivery (DAD) is the software development portion of the Disciplined Agile Toolkit. DAD enables teams to make simplified process decisions around incremental and iterative solution delivery. DAD builds on the many practices espoused by advocates of agile software development, including scrum, agile modeling, lean software development, and others.

References

  1. ↑ "Big Modeling Up Front (BMUF) Anti-Pattern". AgileModeling.com. Retrieved 2023-04-23.
  2. ↑ Joel Spolsky (2005-08-17). "The Project Aardvark Spec". Joel on Software . Archived from the original on 12 April 2006. Retrieved 2006-04-26.
  3. ↑ "A 20 page spec for a 3 month project is a great thing! But it's not BDUF, it's SDUF" Rich Rogers Archived 2006-02-09 at the Wayback Machine
  4. ↑ "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 Archived 2011-05-18 at the Wayback Machine
  5. ↑ "So, of all the things this spec might be, a big, up-front design document is not one of them." Kevlin Henney
  6. ↑ 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.
  7. ↑ Täuber, Johannes. "... programming, technical stuff, agility ..." Retrieved 19 July 2012.
  8. ↑ "How do you design complex systems with TDD?". Start with a rough design idea
  9. ↑ Sedley, Liz. "Rough Upfront Design".
  10. ↑ Kerievsky, Joshua. "Sufficient Design". Industrial Blogic. Retrieved 19 July 2012.
  11. ↑ Cohn, Mike. "Agile Design: Intentional Yet Emergent". Mountain Goat Software Blog. Retrieved 19 July 2012.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.