April 2, 2001

Printer-friendly

RADICAL SIMPLICITY
Simplicity, But With Control

continued...page 2 of 3

ONLINE EXCLUSIVE CONTENT: Simple Twist Of Fate Simplify That E-Mail RADICAL SIMPLICITY SPECIAL: Radical Simplicity Home Page InformationWeek Research: Overcoming IT Complexity InformationWeek Events: The Spring 2001 InformationWeek Conference

The developers collect a number of user stories and estimate how many programming days it will take them to build each piece of functionality. The customers use the estimates to set development priorities and make trade-offs among speed, resources, and functionality.

"Initially, I had serious concerns about XP. They were asking me as a business user to make a large leap," recalls Jim Bahrenburg, VP of product management at Evant Solutions Corp. in San Francisco. Evant developed a complete suite of integrated inventory planning and forecasting, merchandise and inventory management, and decision-support applications. In extreme programming, Bahrenburg plays the role of Evant's customers, the users of the product.

After the user selects the first set of functions, he or she is asked to write the test that will prove the function works. With the test copy in hand--often little more than a couple of lines of script--the developers start writing code to satisfy the test. "It didn't take me too long to realize the power of XP," Bahrenburg says. "The programmers get immediate visibility into what I want, and XP ensures that they're actually doing it."

Of course, users usually aren't skilled at writing tests. "We tried to teach users to write XML tests. Now we're developing a tool that will let them write a test script in plain English and automatically translate it to XML," Bahrenburg says.

Describing the application as small chunks of functionality is key. "You want to slice the requirements small enough for a two-to three-day delivery cycle," says Peter McBreen of McBreen Consulting, a Calgary, Alberta, XP consulting firm.

The payoff from extreme programming comes in seeing fast results. The customer knows within days or hours if the new code does what he or she wants. If it doesn't, the user scribbles another user story or test script and the programmers go back to work.

Ultimately, extreme programming puts the customer, people like Bahrenburg, in control of development. "I'm able to change the sequence of development based on what my customers are telling me," he says. "With XP, these changes can happen on the fly."

Even IT managers who can accept the lack of up-front requirements-gathering or the writing of test scripts before coding balk at the paired-programming approach. XP specifies that development teams consist of no more than eight to 12 people who are paired into code-writing groups. Two programmers sit at a single workstation to write the actual code, analyzing, designing, talking, and arguing as they go. The pairs often rotate to different pieces of the application and the pairing of individual programmers is changed. Within a few iterations, every programmer is familiar with every part of the application and with all the other team members.

From a productivity standpoint, paired programming seems counter-productive; however, studies conducted by Laurie Williams, a professor at North Carolina State University in Raleigh, N.C., suggest otherwise. Williams' studies found that the pairs turned out 15% less code than a solo programmer in a given amount of time. However, the pairs' code had fewer bugs. The savings resulting from fewer defects and reduced bug fixing offset the slower initial code production.

continue on to page 3
return to page 1

E-mail To A Friend |  Printer-Friendly |  Send Us Your Feedback

Home | This Week's Issue | Workplace and Careers | Resource Centers | Research

---