XP Meets XML
April 4, 2001
The XML-Deviant recently spent some time lurking on the Extreme Programming (XP) mailing list. As a result, this week he shares some new acronyms that he's added to his vocabulary, reports on the XP community's lament on the state of XML books, and wonders what the XML and XP communities might learn from one another.
10 Second Guide to Extreme Programming
Extreme Programming (XP) is a software development methodology that has been causing as much of a stir in development communities as has XML. XP is the brain child of Kent Beck and has been around since 1996, although over the last year or so it has been rapidly gaining acceptance by an increasing number of developers. Indeed the Extreme Programming mailing list supports a daily traffic level which rivals XML-DEV at its most vociferous.
The methodology promotes several core principles of which the most well-known and critiqued is "pair-programming": teaming up two developers at a single machine to improve code quality, while ensuring that no single developer takes isolated ownership of a particular section of code -- thereby enabling a higher degree of knowledge sharing. Other important aspects of XP include continuous integration, constant refactoring of code, and a heavy emphasis on unit testing. XP is perhaps best summed up by the maxims which are never far from the lips of any XP developer: avoid BDUF ('Big Design Up Front'), DTSTTCPW ('Do The Simplest Thing That Can Possibly Work'), and YAGNI ('You Ain't Gonna Need It').
Proponents of XP argue that the heavy emphasis on testing, sharing of skills, and incremental deliveries of functionality ensure that XP projects can still be successful and deliver maintainable code, even in the face of shifting requirements. Whatever the truth behind these claims, one thing is certain: XP is popular among developers because it places the emphasis on what they're interested in, the code.
XML from the XP perspective
Intrigued by the XP phenomenon, the Deviant has been lurking on the XP mailing list for the past few months. In a recent discussion about expanding the capabilities of a flat file database several XP developers suggested that using XML rather than a simple record based structure might be a scalable alternative. The responses from other developers on the list were interesting; they were less than complementary.
Robert Sartin characterized XML as breaking the 'small is beautiful' approach.
While writing XML is easy, parsing it is hard. Finding a parser that fits into embedded environments (the context of this problem) might be a tad challenging. Writing code that could handle it would definitely bloat things quite a bit. XML may work, but let's not have the illusion that it is simple.
Other developers agreed, including Ron Jeffries, who suggested manipulating data using regular expressions as a more lightweight alternative.
I concur with this. I'd go with flat files for a while before going to XML unless I had a really light and easy XML parser in my hip pocket. I love XML conceptually, but there seems to be a big first step to get it in. Maybe some simple regexp stuff could be a good start to keep getting stories done at a good pace.
Jeffries was also less than impressed with the current state of XML literature.
... XML is an interesting way to represent any kind of structured data. There are many many tools; there's a translation language to transform XML files to other formats; all kinds of things. Right now, of all the XML books I have, I would recommend none.
Glen Stampoultzis concurred with Jeffries' assessment.
The book situation is sad. I'm reading one now. It's big, it's expensive, it's written by a dozen authors and is driving me crazy! They talk about concepts before explaining them and it's boring as hell.
Echoing a recent lament of many XML developers, Glen Alleman also reported that the shine had faded from XML.
...like all new technology it looks simple and powerful on the surface and turns out to be powerful and complex in the end, when you add robustness, fault tolerance, forward error correction...
It would be easy to dismiss these opinions and return to our work, perhaps believing that the XP crowd just doesn't get it. That would be wrong. This exchange demonstrates that we, as members of the XML community, are failing to explain its benefits effectively, even in an area (simple data markup) which is widely seen as a perfect use case for XML.
Various members of the XML community have been concerned about the growing complexity of XML and related standards. Perhaps it is too late? Has the damage has already been done? Of course it would be wrong to promote XML for tasks for which it is clearly not suited, as this merely adds to the hype. Yet one wonders whether greater promotion of efforts like Common XML might be beneficial, particularly if W3C XML Schemas and RDF are to be the building blocks of the next generation of XML applications.
XP from the XML perspective
An interesting counterpoint to this discussion can be found in the comments from members of XML-DEV during a brief discussion at the end of last year (one which piqued the Deviant's interest in the XP approach).
David Megginson noted that he had adopted some XP principles in his own projects.
I personally use several extreme-programming principles in my work, including starting with the minimum that can possibly work, eliminating duplication, and constant refactoring. These are, of course, common-sense principles that most good coders have been using for decades, but (as with design patterns) seeing them explicitly written down help me to clarify my thinking and understand better what I was doing and why I was doing it.
That said, I feel no sudden urge to do all my coding paired up with another developer in front of the same terminal -- we have e-mail and CVS, after all.
Emphasizing that XP promotes knowledge sharing between developers, Didier Martin observed that pair programming is a good way to share learning of XML vocabularies.
When you create a sophisticated XSLT style sheet you are programming. At Talva we develop a lot of stylesheets and discovered that using the extreme programming practice leads to better written stylesheets and also that the knowledge is percolating more easily among the team members, especially when the team has to master XSLT in addition to: WML, VoiceXML, SVG, XHTML, SMIL.
Tim Bray also praised XP as a methodology, suggesting that it might provide some lessons which could improve the standards process.
Just another data point; XP contains some ideas that seem truly great, but I'm not convinced that you need to buy into the whole package...The really great idea is that of always doing a small number of the next-most-important features first, with necessary refactoring as you go, and repeating this loop until you declare victory.
Why this wins: you would have had to do the refactoring anyhow; and this way, you do it with a good code-based understanding of how your key features have to work.
...As I've been saying in public, I think the people in the standards-building process could learn some valuable lessons from XP.
Given recent discussions about the need to refactor and simplify several XML standards, Bray's comments seem particularly close to the mark. While the XML community may already be benefitting from the use of XP, there are still some lessons which might be learned. And, as the recent exchange on the XP list shows, perhaps this is can be a two-way process.
An interesting project which may help to build bridges between the communities is JXUnit. This is a Sourceforge project, headed by Bill la Forge, that integrates the XML data binding toolkit, Quick, with the unit testing framework Junit. The JXUnit vocabulary allows unit tests and test data to be described in XML, a move that adds to the power of the Junit framework by making it easy to use different sets of test data.
The XML Deviant would be keen to hear from readers who'd like to share experiences of using XP on XML projects.
April Fools
The XML community embraced April Fools Day once again this year, pulling three japes out of its hat. Simon St. Laurent announced the merger of Microsoft, Sun, Oracle and IBM under the banner of the W3C; Aaron Swartz published the XML Kitchen Sink standard; and Sean McGrath requested details of any prior art in the encoding of XSLT transforms as molecular structures, pending a patent application by Dr. Uvbin Hadson.