Big Design

An attempt to define BigDesign on its own terms, which means trying to say what it is in fairly attractive terms on a neutral framework. Commentary on the attractiveness (or not) of BigDesign go to BigDesignCritique. Corrections to what BigDesign actually intends to mean go here.

Few methods actually advocate solving all your problems on paper before you solve them in code. BigDesign is a DevelopmentStance that is instantiated in several currently popular methods. Here are some common features of BigDesign methods:

Formality. BigDesign methods are decidedly not willy-nilly in their approach to software development.
Formalized design documents, including UnifiedModelingLanguage (UML) charts, detailed use cases, and formal sign-off procedures for decision-making.
Very high percentages of design-time (versus code-time) compared to the length of the release cycle, e.g. 30% or more, usually placed right at the beginning of the cycle.
A distinct design phase that is intended to capture all major decisions and most minor ones before any coding begins.
A system of responsibilities that tends to separate thinkers or planners of various sorts from doers or implementors, e.g. Architect vs. Coder.
Extreme attention to vocabulary, removal or clarity of all ambiguities, as if the natural language discourse associated with the above was a form of code, telling people what to do.

As a DevelopmentStance, BigDesign has made a strong historical case for itself, primarily by contrast to CowboyCoding. This stance is one of intense pre-meditation. Historically, BigDesign has spent a lifetime criticizing the cowboy way, defending itself from that way, and ultimately justifying itself by its dramatic improvements relative to the CowboyCoding stance. It is still not the case that BigDesign dominates the scene.

BigDesign developers are committed to maximum thinking up front. The basic BigDesign contention is that decisions that are made using the cowboy way are dangerous for at least two reasons:

First, because such decisions are likely to be trivially wrong, for their failure to take into account important factors that are not immediately obvious to the decision-maker. Computer programs are big and complex, and many seemingly minor decisions can have huge impact on the program-at-large.

Second, because ad hoc decisions tend to be instantiated in a broad, vague, and distributed fashion, they are quite likely to be resistant to change, improvement, or maintenance.

This stance usually involves some companion views. These are not so much a required part of the theory as they are an implicit constant companion to it, probably for historical reasons.

BigDesign seeks to control change, by obtaining early and generally once-for-all signoff on requirements and architecture. Most actual BigDesign methods have detailed structures for responding to the inevitable external changes that will occur, but these mechanisms are often seen as somewhat secondary to the process.
BigDesign sees any uncertainty as a danger. If we don't know something, we can't reason about it. By eliminating all uncertainty in our vision, we are providing the fodder for the planning process and increasing its likelihood for success.
BigDesign places a very heavy emphasis on writing things down. This follows naturally from our desire to rationalize the software process. Theoretically, written documents help to control change, make sure we've covered all potential problems, and identify uncertainties that need resolution. Practically, written documents form a shared knowledge base, and can be used in myriad ways to support the business of developing software.
BigDesign takes advantage of the fact that some individuals are better-qualified to make some design decisions than others. So it seems only logical to divide the labor between those who are good at making these decisions, and those whose role is best defined as carrying the decisions out.

: Do people equate UML diagrams with BigDesign?

I don't equate the two. I like class diagrams as an architectural notation. I like use cases as a way to expose unfamiliar or inconsistent problem domains. I like deployment diagrams as a way to map logical to physical architecture. I use sequence and collaboration diagrams when CRC needs recording. I'm frustrated by the UmlCaseVultures inability to represent the range of things I'd like to model, but usually I can live with that. I suspect that the reason I like these parts of UML is that I don't use Smalltalk, but a guy's got to make a living ...

I'm actively attempting to combine the practices of XpAndUml, and I'll be putting up a document describing my take on this shortly. On the latter I bow to our wiki XPerts in all things, and hope they'll give it a hard critique.

I guess what I'm saying is that UML is a necessary evil on many occasions even though I see a great many UmlTotalFailure(s). --PeterMerel

That's exactly what I was looking for. Is there any other place where XpAndUml are discussed jointly?

Outside of wiki there is also:

Using UML is not ipso facto BigDesign, in my view. I frequently make sketches using Rose, print them out, then a few days later throw them away, which is hardly BigDesign behavior. But due to both its historical development and its key advocates, UML is intimately related to BigDesign: The fact that the three amigos are BigDesign'ers, and that UML is their baby, is inevitably going to make UML seem BigDesign'ish in many people's minds.

UML is not intrinsically linked to BigDesign, and I think you would find that neither GradyBooch nor JimRumbaugh advocates BigDesign - at least as described on these pages. (I happen to be a fan of SmallDesign?, but I have a hard time watching people being untidy in their arguments.) -- AlistairCockburn

Alistar, would you agree that there is a difference between BigDesign and HeavyWeightMethodology??

I'm tempted to suggest that the OO HighPriests? have, to some extent, managed to do away with HeavyWeightMethodology? while keeping BigDesign, at least in that they see everything as modelling. Witness the very high formallity of UML and the very high PercentageOfDesignTime. (Depending on whether you consider UML to be documentation or code.)

--BenAveling

I would expect that a HeavyMethodology? would contain a BigDesign as a component. We no longer see a requirement for fully decomposed structure charts down to the leaf level before coding, so there is a lightening there, and they do recognize increments, iterations and prototypes. Unhappily, I can't see that the high priests of OO have gotten rid of the weight - witness UML Process and RationalUnifiedProcess, light though their proponents would like to believe they are. KentBeck, MartinFowler and I are all trying to counteract this weight, in our own ways. I just agreed to be a series editor for Addison Wesley on a series of books on light-weight methodology elements. The draft of the central book is emerging, the digest of it I posted at [1]. The point is that I disagree with the weightiness of even the amigos' methodological recommendations - or else they keep changing their minds depending on who they are talking to, or else they just haven't learned how to say what they mean. The result is that when I show up on a project, I cringe at the amount of paperwork / screenwork people are being asked to do, without a sense of what that is about or how to detect diminishing returns. That being said, I would say that I now encounter all manner of variations about how much BigDesign to do, maybe I've been crossing cultural boundaries a lot, but I've seen the entire spectrum in the last few months. --AlistairCockburn

My sense of the ThreeAmigos is that its not really a methodology in the true sense. You can't map it to a DevelopmentLifeCycle?, everything is just modelling and once you've done your model you've finished. Whether the modelling is done with a WaterFall TopDown approach, or a CodeAndHack? approach is never really specified. That's why I thought the distinction between HeavyWeightMethodology? and BigDesign was useful. --BenAveling PS I liked your MethodologySpace paper.

Here's my question about BigDesign in its own terms. BigDesign claims to be formal. Does it care about formally provable correctness?