Tue Oct 19 10:29:00 EDT 2010

Big Design Up Front can't work

There are a couple of different approaches to designing software. One popular approach in big companies is to try and emulate the way design is done in engineering and construction, starting with lots of planning and design by 'experts' who then give the plans to 'laborers' to go build. In software circles this is often called Big Design Up Front, and generally speaking it never works well. To get good results costs far too much time and money for most software companies to bear.

There's a good reason why BDUF works for making physical things but doesn't work for software, and it's not something that can be changed. With physical things, at some level details don't matter anymore, but with software the details matter all the way down to the hardware.

Let me give an example: if you're designing a bridge, you can draw blueprints on paper which shows girders. The girders are described by giving their dimensions (accurate to 1/16th of an inch, say) and the particular alloy the girder is made from. This is sufficient to accurately model how that girder will behave under all kinds of different stress loads which is important for ensuring the bridge will be safe, and also to model how the girders will fit together like a puzzle which is important for allowing the steelworkers to build the bridge correctly, on-time, and on-budget.

The key to all of this is the fact that you don't need to create a real girder in order to test the design and make sure it's correct. A few easily described properties of the girder are sufficient; it doesn't matter where every atom goes, it doesn't matter if the surface isn't perfectly uniform, it doesn't matter if there is some rust, etc. Lots of the details just don't matter at design time, and most of them don't matter at construction time either.

Software just doesn't work this way. Software development languages are extremely detail-sensitive: get one letter wrong, one punctuation character in the wrong place or left out, and the software won't work right. There is no way to accurately model something this sensitive to detail without building it first, and if you have to build it first you lose the biggest benefit of doing design up-front: the ability to test and iterate on your design cheaply before committing to a full build of it.

Some modeling does happen in software design, of course. The models are typically imprecise diagrams and textual descriptions of what the software needs to do, lacking most of the detail of exactly how the software will actually do those things. These aren't the equivalent of blueprints, they're more like conceptual drawings that architects create of buildings and bridges before the engineering designs start. You can't jump from a conceptual drawing to construction on a bridge, but that's what most software firms doing BDUF expect to be able to do with their software designs.

The reality is that software is ultimately designed by the laborer, the programmer who is typing in the source code. That programmer has to make all of the detailed decisions about how the software will work, which requires an understanding of the overall design and purpose of the software. The programmer is assisted by a software architect and technical lead who produce the higher level designs to provide a general direction, but in the grand scheme of things their role is ultimately secondary to the programmer. They teach and guide, while the programmer creates.


Posted by Douglas Webb | Permalink | Categories: Software Development