|
INTEGRATION WATCH: Not So Extreme Programming
By Andrew Binstock
 May 1, 2004 — After several years of jubilant promotion, Extreme Programming (XP) settled into its anticipated role as an alternative methodology for developing software. Now, several years later, IT sites and ISVs have had a chance to assess the approaches espoused by XP and see just how much value they bring to the problem of software quality and timeliness. The results are not encouraging.
First of all, on an adoption basis, XP could hardly be termed a success. IT sites today, as a rule, do not use XP. The closest they come is acceptance of automated testing and limited test-driven development (TDD). Both of these practices are tenets of XP, even though they antedate XP.
However, the full XP is based on 12 practices. The other practice IT sites use extensively today is coding standards. Beyond testing and coding standards, XP is not widely deployed. Advocates of XP attribute this to “fear” by hidebound departments that are unwilling to try new techniques (which is true). However, even small sites and start-ups show no great uptake of XP. Nor is XP evident in open-source projects, even small ones where it would be a good fit.
Second, XP was embarrassed by the cancellation of the C3 project at Chrysler. This project was the poster child for XP. It was begun in 1996 with the mission of getting Chrysler’s payroll off its mainframes in time for Y2K. Kent Beck, the father of XP, was brought in, and he implemented XP and made the project a showcase of the new methodology.
Alas, Chrysler cancelled C3 in February 2000: The deadline had been missed, and the old mainframes were still cranking at full tilt to handle Chrysler’s payroll. With Beck running the show, there is no wiggle room for asserting that XP wasn’t done correctly.
While C3 is a terrible black eye, it has not been a telling one. I had hoped to see a revision to XP, which, based in part on real-world failures such as the C3 project, would fix and tweak the things that don’t work well but whose shortcomings were hard to see when XP was first formulated. This would be a mature step that would greatly bolster my confidence in XP.
In counterpoint, UML, the design language that is anathema to XP principles, has regularly been revised. And as a result, it is gaining ground at IT sites. There are more tools today for doing UML than ever before. Drawing and mapping business processes is increasingly a standard part of software development at IT sites—proving that these sites are perhaps not as inflexible as XP aficionados might have us believe.
With a stillborn poster child, so-so acceptance in mainstream IT, and seeing solid growth in antithetical technologies, XP appears to be on the defensive. A new book from Apress titled “Extreme Programming Refactored: The Case Against XP” compounds XP’s problem by analyzing shortcomings of the XP approach. The book is uncomfortably goofy at times, but it makes some compelling points about what does not work in XP. TDD is the one practice that comes out well, which indeed it deserves.
The foundation of XP, in my view, is part of the problem: It is a radical embrace of an approach that goes from the particular to the universal. It is the purest form of bottom-up development: You never design more than what is immediately needed, you write the least amount of code that will fulfill your next test, and you design the test to provide the least amount of incremental change. After you’ve written lots of tests (frequently thousands), you clean up your code by using one of 72 refactorings—which are specifically analyzed techniques for cleaning code without changing its functionality.
The fundamental problem with this approach is that software today is complex and large, so it cannot be designed properly by using the least-increment approach and hoping that a sound product will eventuate through the organic accretion of lots of small design decisions (followed up by code cleaning).
Large, complex projects have to be designed top-down and the code must be developed to that design—regardless of its complexity. XP projects are particularly susceptible to the gap that exists between a project under development and one being deployed. Some projects cannot be fully tested except at deployment, at which point it is too late to perform hundreds of small revisions because of a predilection for a specific coding approach.
An interesting question is: Could XP-based software development have put a man on the moon? I believe the answer is no. XP aficionados might contend it was not developed with that kind of project in mind. And I would agree. Unfortunately, most big IT projects look more like putting a man on the moon than they look like XP’s showcase code exercises of simple designs whose code can be revved in infinite, small increments.
Andrew Binstock is the principal analyst at Pacific Data Works LLC
|
|
Advertisement
Click here for a complete listing of Integration Watch Columns
Click here to see a complete Column Archive. |
Back to Top
|