Dare on Echo: when do you stop growing the spec?

Dare Obasanjo (who has the coolest name of all the MS bloggers) had the following observation in his endorsement of Echo:

I know first hand from working at Microsoft on XML technologies that underspecified specs cost us hundreds of thousands to millions of dollars in wasted effort, lost manpower and customer pain.

Which leads to the question, when is a specification underspecified?

To learn the boundaries of a specification, you need use cases. When do you stop generating use cases? Think of a solution space with lots of local maxima (a topographic map is the image you should have in mind), you’ve climbed a series of peaks, but there may be another set of optimia a valley away.

There’s a tension between doing enough to get the system/project going, and preparing for the future.

How do you leave a spec open for further definition when you know enough to start building against the set of use cases you’ve collected? Namespaces?

Related posts:

  1. Thank You for Spec Writing
  2. Non-Stop to Brazil
  3. Stop using the @#$! NS 4.0 Hacks, dammit!
  4. Dawkins: send hookers to stop Terror
  5. Phil Greenspun on Application Servers

More like this: , .