This article is more than 1 year old

Extreme Programming in risky position, says co-creator

End of opposition breeds challenge

As the celebrated 2.0 incarnation of the web lures an increasing number of organizations into the cloud, enterprise IT managers are warming to the quick-and-dirty capabilities of PHP, JavaScript, Perl, Python, and Ruby for developing database-driven web apps. And a new generation of tools is elevating scripters to the status of go-to guys for trimming development backlogs.

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.

Smalltalk parallels

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.

Next page: Easy reading

More about

More about

More about

TIP US OFF

Send us news


Other stories you might like