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 the 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 equential 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 a business entity that specializes in the development, distribution, and maintenance of software products and services. These companies create a variety of software solutions, including commercial software, custom software, Software as a Service (SaaS), open-source software, and embedded software. They range from small startups to large corporations, engaging in activities such as software development, testing, deployment, and support.

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.

Software development is the process used to create software. Programming and maintaining the source code is the central step of this process, but it also includes conceiving the project, evaluating its feasibility, analyzing the business requirements, software design, testing, to release. Software engineering, in addition to development, also includes project management, employee management, and other overhead functions. Software development may be sequential, in which each step is complete before the next begins, but iterative development methods where multiple steps can be executed at once and earlier steps can be revisited have also been devised to improve flexibility, efficiency, and scheduling.

<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.

Agile software development is an umbrella term for approaches to developing software that reflect the values and principles agreed upon by The Agile Alliance, a group of 17 software practitioners in 2001. As documented in their Manifesto for Agile Software Development the practitioners value:

<span class="mw-page-title-main">Dynamic systems development method</span> Agile project delivery framework

Dynamic systems development method (DSDM) is an agile project delivery framework, initially used as a software development method. First released in 1994, DSDM originally sought to provide some discipline to the rapid application development (RAD) method. In later versions the DSDM Agile Project Framework was revised and became a generic approach to project management and solution delivery rather than being focused specifically on software development and code creation and could be used for non-IT projects. The DSDM Agile Project Framework covers a wide range of activities across the whole project lifecycle and includes strong foundations and governance, which set it apart from some other Agile methods. The DSDM Agile Project Framework is an iterative and incremental approach that embraces principles of Agile development, including continuous user/customer involvement.

<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.

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.

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

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.

In software development and other information technology fields, technical debt is the implied cost of future reworking required when choosing an easy but limited solution instead of a better approach that could take more time.

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 or software development life cycle 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. 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. 18 April 2023. 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 (26 April 2010). "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.