[
Lists Home |
Date Index |
Thread Index
]
On Mar 4, 2004, at 11:52 AM, Eric van der Vlist wrote:
>
> Digression: for programmers an alternative to 80/20 is XP (extreme
> programming). Unfortunately that doesn't seem easy to adapt for
> specification authors.
>
I mused on this subject in a comment to an article on XML.com once.
http://www.xml.com/cs/user/view/cs_msg/1229
Using XP key concepts from
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" -> make the
spec resemble the intersection of the inputs; all too often, specs look
more like the union of their inputs.
"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, refactor.
Some things don't fit real well, but let's try:
pair programming -> multiple editors? Using a Wiki to write the spec
collectively?
sustainable pace -> don't try to do it all at once, do it in a series
of versions ???
I don't know of any obvious examples where these principles worked.
Maybe RELAX-NG? DOM did some of these things right, e.g. doing it in a
series of versions at a sustainable pace rather than on a death march,
and the HTML version at least was more or less the intersection of what
MS and Netscape did or were planning to do. DOM Level 3 has been
largely test-driven, as has the WS-I Basic Profile of SOAP/WSDL.
XML 1.0 itself is the prime example for "when it gets too complex to
understand, refactor".
|
