Les Orchard has a couple of interesting posts discussing perfection and organic growth Designing for recombinant growth with the lazyweb and MovableType LDAP integration. This gets into the whole worse is better discussion which to me is endlessly fascinating because it’s so against what we’re taught in CS 101 (and what those people wind up teaching everyone else – but that’s another topic).
Anyway, to get along with my wildly speculative post, Les says:
By what processes of design do we best facilitate recombinant growth? How deeply and to what level of detail? How dirty should it be, how unspecified or left with holes or shrugs? (Plants need dirt to grow.) How meticulously clean should it be? (We don't want to attract any bugs.) How much should be chalked up to bootstrapping, and how much should be wrangled and hogtied into perfect working order?
I think the discussion of refactoring in The Pragmatic Programmer is fairly relevant here: instead of falling back to the typical engineering metaphor they use gardening:
Rather than construction, software is more like gardening -- it is more organic than concrete. You plant many things in a garden according to an initial plan and conditions. Some thrive, others are destined to end up as compost. You may move plantings relative to each other to take advantage of the interplay of light and shadow, wind and rain. Overgrown plants get split or pruned, and colors that clash may get moved to more aesthetically pleasing locations. You pull weeds, and you fertilize plantings that are in need of some extra help. You constantly monitor the health of the garden, and make adjustments (to the soil, the plants, the layout) as needed. (p. 184)
As I've mentioned before there are a number of software development practices moving toward a more humane process. And I think the ideas underpinning worse-is-better play a big part in this. The major one in my mind is this hypothesis: there is no such thing as a perfect software design. Have you ever seen or heard of one? What design hasn't been modified over time due to changing needs or conditions?
Once you accept this idea (the whole embrace change thing), you realize you need to get things done by doing them rather than thinking about or planning them. It means that the future you know is limited, so try and make that limited future happen as solidly and cleanly as possible. IME trying to plan for all possibilities means that you'll plan for none of them well. As Les well knows, this is one of the main ideas behind release early, release often: get it out there so it can get some sunlight, water, fertilizer and grow.
I think this is very difficult to accept because it's a leap of faith: you're trusting your team's ability to identify problems and possibilities as they come along versus planning ahead for the problems and possibilities. I also have a suspicion that lots of other types of designers -- architects, urban planners, automobiles -- have these same sort of overdesign tendencies. But because their constructs are real and have a substantial cost associated with tearing them down they have to confront the unlimited possibilities demon earlier. Of course, their failures are generally more notable for their lasting substance as well.