eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Doug Watt cant help it: he still catches himself feeling a bit jealous when fellow programmers tweak his code. But that doesnt stop Watt—a senior engineer in the product engineering group at Woodward Industrial Controls, a unit of Woodward Governor Co., in Fort Collins, Colo.—from being a fan of the new, increasingly popular collaborative approach to application development called XP (Extreme Programming). XP calls for programmers to work in pairs and for continuous code changes and reviewing by a project team.
XP is about being open to change in development, developing better-quality and reusable code, and getting more input from users. Proponents say the methodology is well-suited for the world of e-business applications, where technology and needs might change often.
Broadening XPs use, though, is a big hurdle for software development and IT managers who are drawn to its disciplined approach. They must tackle resistance from unconvinced programmers and from upper management and business users reluctant to embrace major change, experts say. Most importantly, the nature of a companys business and its culture can make or break XPs effectiveness.
“It will work in some organizations cultures, and it wont in others,” said Jim Highsmith, director of eProject management at the Cutter Consortium LLC, in Salt Lake City.
Corporate cultures that embrace collaboration more easily adopt XP, Highsmith said. At the same time, XP tends to bubble up from individuals or a small group of programmers before it reaches managers. That puts the burden on programmers to sell the method to management if XP use is to spread.
At Woodward, Chief Software Engineer Todd Hansell didnt emphasize the use of XP when he was pitching the first XP-based project to upper management. Instead, he focused on his groups move toward creating more reusable code by using object-oriented programming tools such as Java. XP was mentioned in passing, Woodward said, since managers have limited knowledge of programming and might be scared off by concepts such as pair programming out of fear it will require twice as many resources.
Indeed, pair programming is a common concern for enterprise IT groups considering XP. They will be hard-pressed to changed entrenched corporate practices. Simple workplace changes, such as reconfiguring cubicles and desks to allow two or more developers to work together, for example, will be necessary, said David Medinets, director of research and development for software developer OnProject Inc., who has worked in IT at companies such as Toys “R” Us Inc. and the Prudential Insurance Company of America.
“How many enterprises do you know that can randomly change desk order?” Medinets asked, in Morristown, N.J. “It takes an act of God to move a desk from point A to point B.”
Making XP work, though, takes more than shifting desks. It also involves greater interaction among developers and users, or what XP generally refers to as “customers.” Proponents of XP, such as Bill Bumgarner, partner and chief technology officer at Web site developer CodeFab Inc., find that the toughest sell is to the business side of a project. At CodeFab, where the 30-person staff has embraced XP methods, getting buy-in from clients requires changing their concept of Web development projects from the fixed-time and fixed-price model to one thats more iterative and flexible.
“Its more about achieving a dynamic and ongoing dialogue with the client that makes them feel in control and in ownership of a project,” said Bumgarner, in New York.
Without that dialogue, things can go awry. At Woodward, poor communication between developers and customers was partly to blame for delays when it used XP to develop a service tool for one of the companys industrial controls. The customers that helped set the initial requirements—a process referred to in XP practice as “planning game”—included marketing and field service. Not only did that process fail to foster clear customer needs, but the project usually lacked an on-site customer. The development took about nine months rather than four, Watt said.
Despite those problems, Woodwards Hansell said he believes XP has value for his development group. The first project yielded code of higher quality that will be easier to maintain because the full group is familiar with it, Hansell said.
“My advice to other managers is to approach [XP] with a healthy level of skepticism but create an environment where it at least has a chance to achieve results,” he said.
And if programmers do catch themselves being protective of their work, it helps to remind them that the benefits of working with other developers outweigh loss of independence. “The best part is to work side by side with someone else,” Watt said. “Its a very stimulating environment, and you dont run into roadblocks or mental blocks.”