|
Great article! My pet idea to break through this dilemma is to apply the principles of Extreme Programming to spec production. Choosing http://www.xprogramming.com/xpmag/whatisxp.htm as a starting point:
"whole team forms around customer" -> focus on what *users* of the spec need from it not what the vendors supporting it want to put in it
"series of small fully-integrated releases that pass all the tests the Customer has defined" -> create small specs, make sure they work well before adding onto them.
"common and simple picture of what the system looks like" -> The tendency for XML standards is to be the union of their inputs; they ought to be the intersection.
"simple design and obsessively tested code, improving the design continually to keep it always just right for the current need" -> when specs get too big and complex, or are just plain ugly (the WXS type system comes to mind!), refactor. OK, you'll break things and inconvenience some people, but better to annoy a few early adopters than to suffer a mass revolt later. From the outside, it appears that a refusal to refactor RSS when the need became obvious led to the rapid crystallization of the "Echo" community. As Kendall said, in an ugly situation its very possible to "work oneself into such a state of misery that not starting over from scratch is inconceivable."
Some things don't fit real well, but let's try:
pair programming -> small committees ???
sustainable pace -> don't obsess over time to market, do it right; don't try to do it all at once, do it in a series of versions ???
Anyway, I think there is a middle path between chaos and death-by-committee, but it is clearly hard work and I don't know of any obvious examples where it worked. Maybe RELAX-NG??? Hopefully Echo will be an example we can all learn from!
|
Previous Message
