Site Presented By
Tuesday, Nov 10, 2009
Extreme programming also means giving up a little control -- acknowledging, at the outset, that software development is an imperfect process.
"It's the idea of admitting on Day 1 of a software project that you have no idea what your project's going to look like on a given future date and saying, 'I'm OK with that,'" says Colin Strasser, managing principal of Union Square Internet Development.
The alternative approach, as Strasser and other XP boosters are quick to point out, is the now familiar tale of software industry woe: Company A hires Company B to develop a multimillion dollar software program. The companies draft a contract, complete with specifications, and part ways while Company B writes the software. Eighteen months later, when Company B finally delivers, the resulting software looks absolutely nothing like the program specified in the contract. Or, even worse, Company B meets all the specifications but delivers a product riddled with bugs.
The history of the software industry is rife with high profile examples of this process. In 1997, the U.S. Internal Revenue Service scuttled a software upgrade to the tune of $3.5 billion. In 1995 the Denver Airport spent an extra $88 million, not including lost revenue, to debug its $193 million baggage handling system. Such examples, however, are less scandalous than the overall culture of shoddiness that seems to have infected the high tech industry over the last decade.
"There's a real tendency for business people and geeks to see development as a zero-sum game," says Kent Beck, the Oregon programmer now credited with coining the term "extreme programming." "The suits say, 'Give me more stuff, more stuff!' The geeks say, 'But I have to do a worse and worse job to give you more stuff.' I wanted to get away from that."
Beck traces the XP story back to early 1996. At the time, the Chrysler Corp. had called him in to help bring the company's new payroll system up to speed. In the process of putting the system through its paces, Beck made a troubling discovery: All the paycheck amounts were coming out false. Despite 18 months of development and millions of dollars, the software lived up to the original specifications but couldn't deliver correct data from one component to the next. After a few weeks, Beck found himself in the unwelcome position of telling Sue Unger, Chrysler's chief information officer, that she and her fellow executives had a giant lemon on their hands.
Instead of helping to overhaul the system, Beck offered his professional advice. He recommended that Unger dump the software and start over from scratch. To his lasting surprise, Unger accepted the advice -- with a Solomon-like twist. She put Beck in charge of the new project.
"I said, 'You don't understand. I'm a consultant. I don't do in charge,'" recalls Beck, laughing. "She said, 'You don't understand, I'm Sue Unger. You're in charge.'"
In the mad scramble to give Chrysler something it could use, Beck called upon many of the best practices he'd come across during his career. Early on, he decided to discard the usual whiteboard planning and view system design as an evolving, feedback-driven process.
"It was a combination of preparation and panic," Beck says. "I decided we were going to divide the project into stories. Each story would involve a specific feature that the customer wanted. It would also be something we could test, so we could show that we had fulfilled the customer request."
Writing tests before writing the code eliminated the need for exhaustive specifications, Beck says. It also eliminated the need for a large "quality assurance" team, which in most large-scale projects makes sure a software program obeys its specs.
Beck turned to pair-programming out of a similar desire for economy. The way he saw it, pair programming eliminated the need for extensive software documentation. If a programmer could communicate his ideas clearly to the programmer sitting over his shoulder, chances are, the programmer inspecting the code two years later would find it easier to understand. What's more, having a copilot on each machine would reduce the overall number of bugs.
The more Beck explained, the more solid the approach became. "By the 15th person, it had become fully streamlined," Beck says.
By the middle of 1996, Beck decided to give his management concept a name. Because other methodologies emphasized planning over programming, Beck decided that "programming" should be in the title. Still, "I needed an adjective that would be catchy, descriptive and defensible," Beck says.
Beck says decided to name his methodology "extreme programming" after noting the intensity of extreme athletes. "I wanted my teams to have that same sense of fearlessness in the face of challenge," he says.
Ron Jeffries, a friend and colleague called in to coach the Chrysler team, grabbed onto the term immediately. "The way it was described was we were taking all these practices that the best programmers already did and turning the dials all the way up to 10," Jeffries says.
