|
I'm an XP practitioner and an enthusiastic user of XML. Despite that, Eric var der Vlist's article mainly strikes me as a puzzlement. There are a number of good ideas, but perhaps because of his lack of experience with XP, many of them are solutions looking for problems.
Certainly, I regularly use XML-related solutions in my XP work. One current project generates XML UIs which are fed to XSLT, outputting HTML or VoiceXML depending on how the user interacts with the system. Another uses XML configuration files and saves all persistent data in XML files, eschewing a traditional database. So I'm not shy about using XML when it's the right tool for the job.
And I'm also not reluctant to use technological aids to improve the development process. For example, I use IntelliJ's IDEA, an IDE with tightly integrated refactoring tools (and a good XML editor, too).
But one of the fundamental insights of XP is that simplicity is a virtue. XP advocates keeping track of stories via simple index cards not because we don't know how to create fancy tools to manage stories, but because we've found that fancy tools are much more expensive and much less effective than a stack of cards. We choose in-person communication because it has a higher bandwidth, lower latency, and better user interface than any computer-mediated tool.
XP advocates solving today's problems today, and leaving tomorrow's problems for tomorrow. Anybody interested in trying XP should learn from that. The first step is to try XP as other people do; only once actual problem present themselves should you start work on the solutions.
There's nothing wrong with reengineering one's bicycle, but one should learn how to ride it first.
|
Previous Message
