Extreme Programming

Oftentimes, the little things can make the biggest difference. Consider some of the tenets of a new programming approach: keep the code simple, review it frequently, test early and often, and work a 40-hour week.

Programmer Kent Beck developed extreme programming (XP) while serving as project leader on Chrysler Comprehensive Compensation (C3), a long-term project to rewrite Chrysler Corp.’s payroll application. Beck then spelled out the development methodology in a book titled Extreme Programming Explained: Embrace Change (Addison-Wesley, 1999).

Since then, advocates of XP have cropped up like kudzu and sparked a maelstrom of debate among programmers and project managers who either love or love to hate its ideas.

According to Beck, XP is a lightweight methodology, meaning that it dispenses with much of the usual application development process, such as lengthy requirements definition and extensive documentation, and that it emphasizes keeping development teams small and the code simple.

Instead of creating large functional-requirements documents, an XP project begins by having the end users of the software create user stories describing what the new applications need to do. Functional testing of requirements is done before any coding begins, and automated testing of the code is done throughout the project. “Refactoring”—the frequent streamlining of design and improving of code—is also a core doctrine.

XP devotees say the methodology helps them deliver code more quickly, with fewer bugs. By creating user stories and performing upfront functional testing, Noggin LLC was able to quickly restart a project that had been bogged down for six months while functional requirements were being written, says Kenny Miller, vice president of programming and production at the New York-based entertainment channel.

“With XP, our client was able to see results sooner,” says Wyatt Sutherland, director of technology at New York-based CodeFab Inc., which managed Noggin’s project. “We try to do pair programming, and in all cases, we do unit testing and user-story task creation and refactoring.” CodeFab’s clients decide whether a project will include XP, says Sutherland, and about 60% elect to use it.

XP also requires constant communication between the customer and the developer team, as well as among the developers. Beck advises limiting project teams to no more than 12 developers working in pairs.

Two by Two

Pair programming is perhaps the most controversial aspect of XP. Two developers work side by side on a single assignment. Beck claims this duo approach leads to higher-quality code that requires less time to test and debug.

“Coding by yourself—it’s easy to get distracted; you’re not as disciplined,” says Tim MacKinnon, senior developer at London-based Connextra Ltd. “With pair programming, it’s like having your conscience sitting next to you.”

The start-up reorganized its development space to accommodate XP, he said. MacKinnon brought in special curved desks so the developer pairs could sit side by side and share computers.

But pair programming won’t work for every company or developer. “When XP works well, it works very well—but it doesn’t generalize well,” says Jim Duggan, an analyst at Gartner Inc. in Stamford, Conn. “You can’t sit any two programmers down at a terminal and expect good results, because it flies in the face of why many people program.

“Programmers consider themselves masters and artists,” Duggan continues. “And if you have two artists at the same palette, they’re going to fight over the brush.”

James Gosling, a vice president and fellow at Sun Microsystems Inc., says the company uses some XP techniques, such as unit and performance testing, but it has passed on pair programming.

“I don’t know that people would do it,” he says. “[It gives] most of the people I know the creeps. But for some people, it might make sense.”

It’s not just pair programming that has slowed the adoption of XP. Steve Metsker, software development manager at Falls Church, Va.-based Capital One Financial Corp., cites collective code ownership as being problematic.

“In XP, anyone can change the code,” he explains. “But I don’t want someone to change the threading model or data access architecture.”

Metsker’s project team built a call center application for a now-defunct telecommunications unit at Capital One using XP methods. Although he lauds the productivity gained by such XP methods as unit testing, peer code review and obtaining rapid feedback from an on-site customer, Metsker said his current project won’t adopt full-scale XP.

Still, Duggan says, XP’s focus on core development fundamentals is causing more and more developers to look more closely at the methodology.

“One thing that’s good about XP is that it [simplifies] things developers don’t classically like to do, like testing and code review. And anything that makes developers do that is a desirable thing,” adds Duggan. “But right now, there isn’t enough evidence yet that XP is a breakthrough that all teams should embrace.”