InformationWeek
Defining The Business Value Of Technology
April 2, 2001
http://www.informationweek.com/831/appdev.htm
Simplicity, But With Control
Extreme programming promises speed and flexibility for those who can stomach it
By Alan Radding
hen work on its new data-management system bogged down, Organon Teknika B.V., a manufacturer of blood analyzers, called for reinforcements. Consultant Ken Auer, president of RoleModel Software Inc., responded. But the plan Auer laid out scared Organon's managers. It called for programmers to start writing code in pairs at shared workstations without first gathering detailed requirements, to write test cases before writing any code, and to establish one-month iteration cycles. "There were things we were apprehensive about," says John DeMichiel, an Organon research associate. What Auer proposed turned conventional application development on its head. "I've always worked with having the requirements up front," DeMichiel says. The paired programming also seemed odd. How could it be as productive? And writing tests before writing any code reversed the normal sequence.
Still, there were appealing parts of the plan, especially the fast iterations. Already familiar with Auer from previous projects, DeMichiel knew he wasn't a crackpot. Besides, work on the new data-management system desperately needed to get back on track. Organon Teknika, in Durham, N.C., decided to let Auer do it his way.
Auer's way is a lightweight application development methodology called extreme programming, or XP, and it's the most visible of a number of new methodologies. Despite its name, extreme programming is a well-thought-out set of rules with a growing cadre of adherents. Although it hasn't generated much interest from business IT, it's attracting a near-cult following in developers' circles, particularly among object-oriented programmers and, especially, Java developers.
There's no doubt that extreme programming is a radical departure from almost every accepted IT application development practice. "IT lives in a world of big infrastructure, which is antithetical to XP. To IT people, extreme programming sounds like a bunch of hacking," Auer says. But proponents argue that extreme programming's practitioners follow a very specific set of rules. Kent Beck compiled these rules, based on a variety of informal practices, in his book Extreme Programming Explained (Addison-Wesley, 1999). "XP may have less formality, but we still follow a disciplined process," Auer says.
Extreme programming promises to achieve two goals IT has long pursued: building applications that deliver what the business actually wants and needs, and building quality applications that can be readily changed as business needs change. Given its generally dismal track record in achieving either of these goals, IT needs to pay close attention, especially as it ramps up for the next generation of Internet and E-business applications.
"XP is designed for controlling the unexpected. It assumes that you'll be making a lot of changes. It allows you to inch the project along while you keep the code base clean; just try an idea, code it up, and see the results fast," says Ward Cunningham, one of extreme programming's originators and co-founder of Cunningham & Cunningham, a Portland, Ore., consulting firm. Cunningham built an entire portfolio-management system for fixed-income securities using techniques that were to form the foundation of XP.
IT's favored approaches--the plodding-waterfall development methodology, computer-aided software engineering, rapid application development, and joint application development--have tried to address the application development challenge; none has been particularly successful.
To overcome the problems that plague application development, extreme programming ignores some sacred cows. Instead of up-front requirements gathering, extreme programming calls for the developers to sit down with the users or customers who describe in their own terms what they want the application to do. Through user stories, customers describe a single function or feature in high-level business terms. User stories typically fit onto a single index card.
The real requirements come out through lengthy and frequent conversations between the customer and the developers as development proceeds. "In XP, the customer rules. The customer specifies a set of features in a lightweight way," says Robert Martin, founder of Object Mentor Inc., a Vernon Hills, Ill., training firm that specializes in extreme programming. The index card containing the user story then acts as an aid to jog the developers' memory as the programmers code that particular feature.
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.
 
|
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.
Organon Teknika's experience supports Williams' studies. "We found it to be more productive. It saves us in design and code reviews," DeMichiel says. The pairs are continually evolving the design and catching defects on the fly.
However, extreme programming may complicate the way IT programmers are evaluated and compensated. XP eliminates any possibility that a programmer's individual contribution can be measured in terms of lines of code, function points, or number of class libraries. With extreme programming, there's no individual code ownership; everybody touches all the code. Anyone can change any piece of the code at any point. Design, coding, and debugging are merged in fast, small iterations. Code is continually optimized to reflect the latest changes through frequent refactoring.
"You really have to ask yourself what your goal is," says Cunningham, who says XP lets team leaders and managers know their programmers better than any metrics allow. With coaching and mentoring built into the process, managers quickly discover everyone's strengths and weaknesses.
Given the contrarian nature of XP, it's not surprising that there are few XP showcases among corporate IT. The most prominent example is the Chrysler Comprehensive Compensation (C3) system launched in May 1997. The massive payroll system was responsible for paying approximately 10,000 monthly employees. It was terribly complex, reportedly requiring seven mainframe systems to grind through rules for handling various types of employees. A team of 26 programmers working the conventional way had already failed on this project.
"When Kent Beck got involved, the project was in crisis, nearly dead," recounts Alistair Cockburn, founder of Humans And Technology Inc. in Salt Lake City. Beck, heading a team of eight, used XP techniques to deliver C3 in a year. The application comprised 2,000 classes and 30,000 methods, and the XP team continued to deliver new functionality for the application every month for two years.
Lightweight approaches such as XP are just starting to be taken seriously by corporate IT, notes Matt Light, a Gartner research director. Gartner sees extreme programming as part of an overall shift in business application development toward more flexible, less rigorous, lightweight methodologies, which Light describes as a "just enough" process.
Extreme programming's proponents insist the technique can be used for any application development project. They cite Chrysler's C3 and Cunningham's portfolio-management project as examples of large, complex, business IT systems that benefited from XP. But there are conditions that should be in place before IT managers attempt an XP effort. Foremost, "you must have a customer who can make decisions, not somebody who has to go back to a committee," McBreen says.
Companies are starting to apply XP to client projects, mainly midsize ones that need some process measurement but would suffocate under a big methodology. ClickThings Inc., a New York software company that uses the Web to manage digital business relationships, has adopted pieces of extreme programming, including user stories, short cycles, and small teams to crank out a new release every two weeks. But it avoids paired programming. "Two developers on one workstation? We'd have a strike," says Paul Neilson, ClickThings' chief technology officer.
Between the demands it puts on customers and the way it subverts accepted practices, XP isn't for everyone. However, lightweight methodologies that help IT to quickly build highly changeable apps should be part of IT's project toolkit. Says Light: "You can love light methodologies like XP or hate them, but you need to be willing to use them where they can help."
Photo of Bahrenburg by David Weintraub
Photo of Neilson by Naoto Ikeda
Boeing seeking Software Engineer 5 in Anaheim, CA
KForce seeking Inside Sales Associate in San Diego, CA
Amalgamated Bank seeking Chief Information Officer in New York, NY
Apollo College seeking Medical Billing and Coding Instructors in Albuquerque, NM
Allstate seeking Exlusive Agent in Las Vegas, NV
For more great jobs, career-related news, features and services, please visit our Career Center.
