Little Design Up Front

Little design up front is the process of modeling some small subsystem of a product before you start coding. (Compare with BigDesignUpFront, where an entire project or system is modeled before implementation begins). BigDesignUpFront can often be an AntiPattern for numerous reasons; but LittleDesignUpFront (or numerous instances of LittleDesignUpFront on a project) is frequently useful.

BigDesignUpFront often fall into one of two categories: 1) a high-level architecture document that specifies key architectural details of the system but leaves much unspecified and/or is vague, or 2) TheAlmightyThud--reams of paper design documents that attempt to specify every last detail of the system (but are generally chock full of errors and inconsistencies, as there is no automated way to cross-verify such a document against itself). LittleDesignUpFront is capable of being both precise and concise; many programmers can "grok" a LDUF and spot inconsistencies in it.
BigDesignUpFront is often difficult and expensive to generate and change--often requiring teams of analysts to produce, the blessing of numerous layers of management, etc. LittleDesignUpFront can be lightweight and informal--it often can be done by the programmer simply as a PaperModel, or if reviewed, it can be accurately reviewed by a small team. As LDUF generally affects a small subsystem, the political pomp and circumstance is unwarranted.
LittleDesignUpFront can be an invaluable tool for some in clarifying thinking--TheKeyboardIsTheWorstPlaceToDesign.

But be careful... if a PointyHairedBoss sees LDUF occurring, he may attempt to morph it into part of a BDUF.

I often find it a useful exercise to a) diagram a system on paper (a PaperModel), b) implement it (perhaps making changes to the PaperModel as warranted by the feedback provided by implementation/test activities), and then c) do one of the following:

Correct the PaperModel to reflect the implementation choice--it may become useful documentation to a maintenance programmer, or
Throw the PaperModel away; it has served its purpose--to clarify my thinking and remove a mental block.

Of course, many say TheSourceCodeIsTheDesign--in which case LittleDesignUpFront should exactly be equal to PaperModel.

The Benefit of Little Design Up Front

What is the benefit of doing mental and paper implementations first? There is only benefit if the "design" reduces the time and effort to get to the software implementation. What is the rationale used to justify Little Design Up Front?

When you are planning a trip do you take a look at the map and figure out a route? Do you figure out if you are going to drive or walk? Do you consider if you need gas? Do you need to pack clothes? Is there a hurricane where you are going? In short, you use the same normal human ability to plan and execute that you use in every other part of your life.
For driving, there are benefits to doing trial and error on a map representing the trip rather than during the actual trip. The benefits are that it takes less time to trace a route with a fingertip than to drive it, and that it consumes fewer resources, namely gasoline. This does not imply there is benefit to performing trial and error on a representation of the software rather than in the actual software. The question, remains, what is the proposed benefit?

I find that, in CeePlusPlus at least, a quick CrcCard session saves me a lot of trouble. I'm not quite sure if that would fall under the original author's concept of Little Design.

It certainly would. LittleDesign? means just that--whatever techniques are needed to aid the programmer's understanding of a problem. Scratchings in a notebook or on an envelope do fine; as would a CrcCard.
But what is the benefit? How does a "quick" CRC Card session save any time or effort over just entering the code?
- I've noticed that I use it when I am not pairing, more than when I am pairing. The design is more fluid on paper. It's much faster to move things around and see problems with particular lines of thought. It allows me to have a conversation with myself, which is useful when I am not pairing. I don't know if it saves time in the long-run or not. It's possible that as programming GUIs improve, designing on a computer can be just as fluid as designing on paper.
- If you don't know exactly what code you are going to enter, it can save some rework. Of course, it depends on how you think. Some people can compose designs in their heads, like WolfgangAmadeusMozart composed entire symphonies in his head, and the code-typing becomes a mere transcription exercise. Others like to start with a PaperModel. Others just start coding and expect rework as an acceptable part of the process. Whatever works for you...
- What work or "rework" is being saved? Yes, one can choose many different styles of work, but that says nothing about the benefit of a particular style. It is okay to have a preferred style or a style with which one is comfortable. If one does not know exactly what code to enter, it does not matter what format is used for the initial entry; the initial entry will probably be modified at least once, and most likely multiple times. For a specific format to be more beneficial than others, it must show a reduction in the time to complete the entire task, a reduction in the number of people required to complete the entire task, or a reduction in the cost or amount of equipment required to complete the entire task. What benefit is being proposed for Little Design Up Front or is it an assertion of personal preference?

The main aspects of LittleDesignUpFront (on BigDesignUpFront; someone suggested a better title--LittleDesignAllAlong?) are:

Highly informal; can be done alone, with a pair, or with a small team of programmers. No ceremonial aspects whatsoever.
Done on small subsystems--i.e. one class, function, or package.
Often non-prescriptive--the results are to be used as advice, not requirements.

Another way to look at it is the LDUF is strictly a programmer's tool; not a manager's tool (DistinguishProgrammersAndManagersTools). BDUF is frequently the latter; more often than not a BDUF is done so that management has (often false) confidence that adequate due diligence is being paid to design. The problem, of course, is that one of the following occurs:

The BDUF is prescriptive--the code must follow the paper design; any deviations require management intervention. Counter-productive for numerous reasons already mentioned.
The BDUF is done, management grants its benediction--and the design is summarily tossed in the circular file. Not all at once, of course, but as the realities of implementation start to batter the paper documents (and the resulting design changes propagate throughout), the BDUF soon becomes a work of fiction; bearing little resemblance to the code. LDUF has the same issues; but being informal and limited in scope is far easier to change.

See: BigReductionUpFront