February 23, 2003 - reprinted with permission from The Dallas Morning News

Hand-to-hand Teamwork

Extreme programming takes hold in software collaboration

By Alan Goldstein

SOUTHLAKE – Many of the programmers at Sabre Holdings Corp. work in pairs sharing a keyboard, but it's not because the company has a shortage of computers.

They stand around conference tables for meetings, leaving office chairs unused. And they plot their progress by moving index cards across a bulletin board, ignoring automated programs available for managing projects.

These developers are disciples of a new and rapidly growing movement that takes a radical approach to some of the software industry's biggest problems: Poor quality. Runaway budgets. Missed deadlines.

It's called extreme programming.

"The name evokes images of extreme sports, of something that's risky and out of control, but it really is just the opposite," said Brad Jensen, senior vice president for airline products development at Sabre. "It is highly disciplined and controls the risk."

Extreme programming, sometimes called XP, represents a far more collaborative approach to how software is made, with lots of emphasis on communication. Team members share keyboards because it forces them to talk out each line of code – and keep it simple.

They have short daily meetings and stand so the sessions don't drag on. They demonstrate their progress with a wall of index cards so everyone can easily see what needs to be done next.

Extreme projects are heavily planned – divided into pieces, each of which can be completed in two or three weeks. That way, the team can regularly deliver working software to the customer, helping to ensure that everyone is on the same page.

Shorter design timelines also improve quality. So do tests that are prepared before the code is written, reversing the usual order. The thinking is that if it's hard to write the tests, the design is probably poor. Every night, the code that was written that day must meet production standards.

At a time when software almost every aspect of modern life, technology experts agree that it's grown unnecessarily complex and that its quality isn't improving.

If anything, they say, it's getting worse.

Defective software costs U.S. companies more than $100 billion annually and accounts for 45 percent of computer downtime, according to the Sustainable Computing Consortium at Carnegie Mellon University, a collaboration of major corporate technology users, academic researchers and government agencies.

The steep drop in spending on technology that began more than two years ago is largely a result of customers' frustration with poor quality software and badly managed implementations, said Dr. Leon Kappelman, director of the Information Systems Research Center at the University of North Texas in Denton.

"The tech spending slump is largely self-induced," he said. "We have brought this upon ourselves."

Latest improvement
Extreme programming is only the latest term for a series of efforts over the decades to improve how software is made, Dr. Kappelman said, noting that other initiatives also have focused on using small teams and breaking projects into segments. "We've learned a lot in the interim, and this is the latest incarnation," he said.

Proponents of extreme programming say it's impossible to quantify its productivity benefits because people have different responses to the changes.

Still, some companies have calculated remarkable gains. NextJet, a supplier of transportation management software, has reduced the production time on 18-month projects to nine months, with the same number of people.

Lots of software engineers initially approach extreme programming with a healthy measure of skepticism, believing it's just an excuse for having fun or even goofing off, said Paul Orsak, chief technology officer at NextJet Inc. in Dallas, which has also adopted extreme techniques.

"But once they've tried it, our experience is they become believers."

It's as if an artist commissioned to paint a landscape came back to the customer every few weeks to ensure the trees and water were done right, said Mr. Orsak.

At Sabre, peer pressure to stay engaged and the more frequent deadlines keep people working harder, said officials for the Southlake-based travel technology company. In addition, quality has vastly improved. In two cases, software products were rewritten entirely with XP, and the defect rate was less than 10 percent of that in prior versions.

"You catch the bug before it goes in," Mr. Jensen said. "You don't need to have a long debugging process at the end, where you're looking for needles in the haystack."

Although a lot of software companies have accepted the principles of extreme programming, many say they find it difficult to embrace changes in the traditional "lone geek" culture.

International Business Machines Corp., for example, has adopted aspects of extreme programming, such as producing smaller releases and putting products in front of customers for tests.

"We're not literally sharing keyboards," said Jim Rhyne, a software architect for IBM in San Jose, Calif., but that's largely because some buildings have separate offices for each developer.

Farmers Branch-based i2 Technologies Inc. is also customizing its interpretation of extreme programming.

"We're not believers that there's a cookie-cutter solution to every problem, and the XP extremists say you have to do everything XP," said John McGhee, a director in the total quality management program at i2, which makes software that helps companies track and manage shifts in demand for their products.

History of XP
Extreme programming was created in 1996 when Kent Beck, a software consultant, was called in to help the former Chrysler Corp. rescue a failing effort to write payroll software. Chrysler had blown through millions of dollars on a classic runaway project with little to show for the work, said Mr. Beck, now known as the father of extreme programming. (He joked that he prefers the moniker "grand pooh-bah.")

Mr. Beck told Chrysler executives it would be a shame to cancel the project, considering the investment the company had made and the experience the team had gained.

Because it seemed a logical way to turn around a chaotic situation, his first order of business was to set a goal for the first three weeks: The team had to be able to print a check. It worked, and that's how the short-term iterations were born.

Mr. Beck began to improvise. Each function, he determined, would be called a "story," a term that's regularly used in XP culture. "Inspiration is a combination of preparation and panic," he said.

By the time the Chrysler project was finished, "it was obvious this was a whole new thing," Mr. Beck said.

The name came next.

"You need a name that's descriptive and catchy but also defensible," said Mr. Beck, who in 2000 formed the Three Rivers Institute in Merlin, Ore., and now travels extensively preaching the gospel of XP.

"The word extreme comes from extreme sports. People who are serious about extreme sports ultimately are prepared. They have the best possible equipment. If they're going whitewater rafting, they carefully map the bottom. They don't just go, 'Oh cool, nobody's done this before,' and jump in a raft. The risk is not what it looks like to the outsider."

Noisy collaboration
The room where Sabre groups its developers together for airline products is noisy by design.

Not only does Mr. Jensen want his programmers to communicate with one another as they're teamed at the same keyboard, he also wants them to overhear nearby conversations and pitch in suggestions.

"You want the knowledge in the group, not in someone's head," he said. "We want collective ownership. Everyone owns the code."

In XP, individuals are forbidden from taking exclusive responsibility for any bit of programming.

This is in stark contrast with much of conventional programming, in which heroic "cowboy coders" have kept projects afloat through generating enormous amounts of work, generally in isolation.

But the disadvantage that many organizations find in having only one person understand a clever bit of code is that the person isn't always available when changes are needed.

In XP, programming is far more flexible because changes can be made quickly by anybody. So if Sabre needs to add biometric or smart card readers to airport ticketing systems that now read barcodes, the old code won't have to be ripped out to allow for the added functions. "

We don't have to worry about whether the expert is out of town," said Jay Packlick, a senior product architect at Sabre. "I can take vacations."