Extreme Programming in risky position, says co-creator
End of opposition breeds challenge
Of course, with "mainstream" comes "methodology," and we've reported here the very cogent arguments of Zend senior PHP engineer Eddo Rotman that webhead scripters who want to be taken seriously in the enterprise might find just what they need in agile development schemes.
Despite growing opportunity for adoption, though, one of the industry’s most popular agile methodologies, Extreme Programming, or XP, has reached a “risky” stage in its evolution.
That’s according to XP co-inventor Kent Beck who published his first book on XP eight years ago. The XP approach is mainstream now, but only in the sense that virtually no one is opposing it. It's accepted, but not to the extent of, say, the integrated development environment or open source software.
"We don't yet have the advantages of whole-hearted, widespread adoption," Beck told Reg Dev during a recent interview, "but we no longer have the disadvantages of a vigorous opposition, either. This is the stage at which an innovation can just die. Everyone says: 'Oh yeah we do that,' but they really don't, and there's not enough opposing energy to push them into really doing it."
XP is now one of the industry's most popular lightweight software development methodologies. With roots in the Smalltalk community, it's a system of practices that emphasizes such principles as collective code ownership and practices such as pair programming.
Beck, founder of the Three Rivers Institute and a speaker at QCon 2008 in London this week, sees Web 2.0 development as going through a phase - with its cowboy coders and "don't-fence-me-in" attitude - that is reminiscent of the early coder culture surrounding Smalltalk.
"In the early days of Smalltalk, you were supposed to have this Zen-like oneness with your program," Beck said. "If something was wrong, you would feel it somewhere in your body. That worked out about as well as you'd expect: okay, if you're working on small programs by yourself, but not so great when it comes to a bunch of people needing to deliver software to a bunch of other people over a long period of time."
Over the course of four or five years, the Smalltalk community lost its "I'm-an-artiste-who-needs-transparency" attitude, Beck said, and figured out that it needed at least some of the disciplines that were common in J2EE and C++ shops. Beck and others built some of the tools and mostly rediscovered the techniques necessary to do just that. SUnit, a precursor of JUnit, was one result.
Despite the growing popularity of the "quick and dirty" dynamic languages, Beck sees the cowboy coder as a dinosaur, a creature of a phase generally fading from the software development industry. Programmers today want the discipline, he said, and they're looking for ways to be more businesslike while retaining the technical excellence that underlies really top-notch execution.
The evolution of the current crop of dynamic languages "seems to me to be very much in that spirit," Beck said. "It's one of those things that just keep coming around. We [Smalltalk developers] forged ahead with a powerful new tool, shed the shackles of the past, and then realized that some of those shackles weren't shackles at all."
If that's true, it's a change that will be especially useful in the enterprise, where the byword is "sustainability".
"Your organization is going to spend a lot more on somebody - you or somebody else - reading what you're writing right now than they are ever going to spend on you writing it," according to Beck.
"You're going to read that code yourself 10 to 100 times for every time you write it, so it's worth taking the trouble to make it readable. You're going to modify it five times after you write it the first time, so it makes sense to make it easy to change. And because you can't predict the future, it doesn't make any sense to build a lot of stuff you don't need right away. These are unchanging principles of software development, and nothing about applying the words 'scripting' or 'model driven' or whatever the programming metaphor du jour happens to be changes any of that."
The basic principles of agile development haven't changed, either, but XP has evolved. The technical practices are more or less the same, but a number of XPers - Beck included - are less interested in them and more focused on the human aspects of the methodology.
"At this stage, it's not so much about how we can push these technical practices further," he said, "but how we can be more accountable. How can I work in a transparent way? How can I give everyone who needs information about my work the information they need? How can I take responsibility for the value of what I create?"®