Site Presented By
Sunday, Nov 8, 2009
"Extreme programming" sounds like no more than a marketing-driven fad, but fans are convinced that its rules hold the key to better code.
May 29, 2002 | The bug was trivial, nothing more than a missing letter. In a normal document, spellcheck would have caught it easily. In a software program filled with dozens of dyslexia-inducing commands, pseudo-words such as "CallOutOriginal," "CallOutCopy" and "CallOutFormRequest," it lurked invisible, and dangerous, like a piece of broken glass on a linoleum floor.
As Eli Collins, a programmer with the New York-based software firm Union Square Internet Development, scoured the list of error messages, Tom Clarke, Collins' colleague and "pair programming" partner for the afternoon, made the discovery.
"I think I see it," said Clarke.
"Where?" asked Collins.
"Right here," Clarke said, pointing toward a line of source code on the screen. "Looks like you left out the second 'i' in 'original' on line 172."
Within seconds, Collins, the designated typist, had fixed the error. With a click of the return button, the program was running once again through a battery of internal tests written by the two-man coding team over the last two weeks. This time around, the offending red tinge signifying a failed test was gone. The program's status bar showed solid green. Zero failures. Their newest feature, a point-and-click editing command, had received the green light, literally, and Collins and Clarke were ready to move on.
"Ah yes," said Clarke, leaning back while Collins piloted the machine. "Yet another example where having a second set of eyes helps."
In an era of cheap, portable computers and universal connectivity, the image of two people working over the same keyboard seems about as quaint as an RCA vacuum tube. For a growing number of programmers, however, it's the latest thing: "pair programming," a cornerstone tactic in an emerging grass-roots software development methodology sweeping the industry.
The name used to describe that methodology varies. Some call it "agile programming." Most call it "extreme programming," or "XP" for short. Whatever the name, the methodology's tenets boil down to an intriguing mix of age-old developer wisdom, newfangled coding tactics and a sugary-sweet layer of marketing-speak. Depending upon on whom you talk to in the software industry, it's either the biggest breakthrough since object-oriented programming or the biggest pile of hype since "push" technology.
"XP improves a software project in four essential ways: communication, simplicity, feedback, and courage," reads one XP booster site.
"XP is like a ring of poisonous snakes, daisy-chained together," counters another. "All it takes is for one of them to wriggle loose, and you've got a very angry, poisonous snake heading your way. "
The truth about XP, which is no relation to the Microsoft operating system Windows XP, actually lies somewhere in the middle. Communication is certainly the key component of any XP project. Designed to overcome the endemic problem of programmers promising one thing and delivering something totally different, the XP methodology is built around putting the face-to-face interaction between developers and customers -- not to mention developers and developers -- over the keyboard instead of over the conference table. XP's underlying article of faith is that if programmers and customers just communicate better, quality software will be the natural result.
