Writing partial designs

I recently kicked off a piece of development work and then handed over leadership of the small team to someone else. The new leader is keen and thorough, but I don't think I've really persuaded the rest of the team of the value of writing down partial, incomplete designs.

The developers in the team seem to have the impression that doing design involves solving all the problems and then writing up a solution. But it's much better, as I've mentioned before, to use a design document as a work in progress which records the solution so far and has placeholders for all the known problems. Such a 'live' document can be shared with other people and used to stimulate new ideas and solutions.

Rock climbing provides a good analogy. A team can climb up a rock face without pausing to bang in pegs. But then one person's achievement in reaching a particular point of the climb can't be shared by those following behind. Also the effects of a fall can be catastrophic.



In a similar way, writing down partial designs enables a team to build on each other's progress. If a major design problem turns up, it is often possible to reconstruct a solution from the remains.

This sharing of design information can be done verbally, but this lacks the precision of a written document and doesn't force out so many issues.