Extreme Programming Examined is an anthology of essays about XP. There are 33 essays, organized in 7 parts. (Yes, this is very thick for an XP book...)
I came across this tidbit in Chapter 2, The Tao of Extreme Programming. As you are probably well aware, XP is very much against the "standard big methodology", where lots of documents are created (taking huge amounts of time away from actually writing code...). While the association with Taoism, Confucism or Jedi-ism may or may not be to your liking, I found this passage to be quite profound:
Traditional methods document the artifacts of schedule, budget, requirements and design in order to control development. These static artifacts capture the intention of a project, yet they fail to account for its tao, its flow. The flow of development erodes old intentions and creates new ones, forcing an ever widening gap between artifact and perception. The effort needed to complete, correct and maintain consistency between artifacts increases exponentially with the scope of a project, yet even small developments may swiftly overrun their banks.Lots has been written about why XP is the savior of all software as we know it. Lots has also been written about why XP is nothing more than a flash-in-the-pan rediscovery of one or two old-school techniques (testing, iterations) that recur every so often (but are somehow incapable of addressing the concerns of software development yesterday, today or tomorrow).
Believe what you want. This quote really summarizes what many programmers feel is wrong with development as we know it today, and how a total rethinking of "methodology" is in order (XP or otherwise).
Flashback to "XP and Open Source"...
chromatic on 2002-02-12T00:56:22
"... and the Slash guys sitting right here, they don't write tests!"Okay, so I might be a little bitter because I'm writing unit tests for Everything, exposing and fixing several bugs and trying to figure out how some features ever worked.
:) Re:Flashback to "XP and Open Source"...
pudge on 2002-02-12T01:23:11
Yeah, but we don't have those problems.;)
Our biggest problem is documentation, which as I understand (?) XP isn't big on to begin with.Re:Flashback to "XP and Open Source"...
chromatic on 2002-02-12T06:27:51
Dare I suggest "Issue Mode" as a Slash feature which seems to work, yet defies all resonable attempts at explanation?
I can't point at any one particular source, but don't believe XP eschews API or end-user documentation. The idea seems to be "Travel Light" (no adverb, sadly). PERT charts, UML diagrams, reams of detailed specifications, and even code comments have a way of going out of date. XP suggests to avoid them, unless they really help.
(Of course, if I were strict I'd say "NO documentation would be better than the documentation that says This is a function for Blah blah blah..."
:) I dare anyone to read the meta-moderator reconciliation code and tell me it doesn't need comments. Re:Flashback to "XP and Open Source"...
pudge on 2002-02-12T14:11:59
I thought we explained it already in some email or other. It works as it was intended to work, insofar as it was completed, which isn't very far.:-)
As to some of the metamoderator code, I do not accept your dare to look at it.:-) Re:Flashback to "XP and Open Source"...
ziggy on 2002-02-12T15:49:51
The best source to point to is Beck's Extreme Progamming Explained. The party line is that the individual aspects of XP are self-reinforcing, but only when practiced under ideal conditions. One ideal condition is the team of 5-7 people working for a prolonged period of time together on a single XP project. Turnover is not addressed, nor is handoff to another team.I can't point at any one particular source, but don't believe XP eschews API or end-user documentation. The idea seems to be "Travel Light" (no adverb, sadly). PERT charts, UML diagrams, reams of detailed specifications, and even code comments have a way of going out of date. XP suggests to avoid them, unless they really help.This is simultaneously a strength and a weakness of XP. On the strength side, XP focuses on delivering working code, and to that extent documentation of what was working yesterday is irrelevant (especially since it is changing constantly). On the weakness side, turnover and handoff happen. (In the Open Source side, loss of resources is less important than the gain of resources; if a project is set up in such a manner that inhibits the addition of new developers, it's long term longevitiy is questionable.)
The XP response is that "documentation is simply another deliverable". If the customer needs copious amounts of documentation, then that needs to be factored into the planning game. That documentation can be written user docs, maintenance docs, UML diagrams, PERT charts or whatever the customer needs. However, it's also going to be a drain on coding resources that must be addressed by the customer.
Also, the 5-7 member team doesn't need as much co-ordination as a 50-200 member team, so the drive to document everything is less pronounced, and the 5-7 programmers really can keep everything in their heads, especially in the presence of pair programming, constant integration and pervasive testing.
Alistair Cockburn talks about this in his Agile Software Development. XP is only one agile methodology (er, approach). Cockburn has developed an entire family of approaches under the umbrella of "Crystal". He addresses some of the relative strenghts and weaknesses of XP and some of the Crystals.
Re:C'mon Adam
ziggy on 2002-02-12T15:36:29
I could have used 'approach' instead of the M-word. But I find myself reading a bunch of M-word books at the moment. Alistair Cockburn's Agile Software Development is very good and spends a lot of time talking about the M-word (in terms of "how do we do work around here"?). His basic take on the matter is that there's one intrinsic approach per project, and that the approach is influenced by other approaches and specially tuned to local circumstances. The important thing to note though is that this happens whether it is done actively or implicitly, and that there is benefit from re-using aspects from relevant lightweight approaches.Unfortunately, however distasteful, the M-word still seems to fit better than the more generic word "approach".
:-S
