InformationWeek
Defining The Business Value Of Technology
|
April 2, 2001 |
 |
RADICAL SIMPLICITY
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.
Photo of Neilson by Naoto Ikeda
 E-mail To A Friend | Printer-Friendly |  Send Us Your Feedback |
|
|
