Big Design Up-Front

Or Different Circumstances, Different Effectiveness in Techniques

Traditional approaches (read “plan-driven”) will dictate that you first specify in detail what you want, before you start building the software. In the rigid approach, where you may not code anything before the design is approved, we call this the “Big Design Up-Front”.

Photography by HouseOfText.

We all know that the Big Design Up-Front (BDU) that we all used in the old days is dying out. Its purpose is to define everything that has to be built up front, so the process is nice and predictable. In the last decade, we found out that this is not such a good idea after all. The requirements change or are even unknown, so what is specified up front will be wrong, anyway. BDU, as a tool for feedback to the end users on what has to be built, is dead (or should be). The lean and mean validation process of short iterations and close end user cooperation provides more promising results.

However, feedback and validation to end users is not the only purpose of BDU. The design is also used to solve risks of miscommunication between parties and can be used as a formal document (as for contracts). If you have multiple parties that are not in the same geographical location but are working in parallel on highly connected system components (like interfaces), you might need a big design in the beginning. It will function as the main source for all parties to perform their tasks.

If you are going to work in a highly political, blame-it-on-the-other-guy environment, you’d better over your back and create a large document in the beginning describing what you are going to create, to be part of the contractual agreements.

Some professionals might have the tendency to take an attitude like, If they can’t tell me what they want, we shouldn’t even bother. In theory, you should be able to get at least close to 80% on paper up front. But sometimes it is wiser to support the users in their “I know what I want when I see it” mood just to be able to proceed and to get something useful. This is better than forcing large requirements and design sessions and having binders of documents that are mostly hard to read for end users (if they read them at all).

This is a sample of how techniques can be helpful under different circumstances. Even the old techniques everybody complains about (or defends heavily) serve their purposes. Also, the agile alternatives to BDU (iterative, close user involvement, and so on) have their risks (in no particular order, and without any intention of being complete):

• Miscommunication when there is a distance in team members in time or geographic location
• More vulnerability to changes in project team members
• Shorter planning horizon, so more difficulty in planning/estimating costs for the whole (not every customer can handle this)
• Risk of requirements inflation (end user communicates directly with developer)