SIDEBAR: Learn More . . .

Previous Articles in CIO

• Jack Be Nimble, Jack be Quick, CIO, October 2002
• Secrets to Software Success, CIO, August 2001

Books

• Refactoring: Improving the Design of Existing Code, Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts, Addison-Wesley, 1999.
• Refactoring Workbook, William C Wake, Addison-Wesley, 2004.
• Agile Software Development Principles, Patterns and Practices, Robert C Martin, Prentice Hall, 2002.
• A Practical Guide to Extreme Programming, David Astels, Granville Miller, Miroslav Novak, Prentice Hall PTR, 2002.
• Data Sharing Using a Common Data Architecture, Michael H Brackett, John Wiley & Sons, 1994.
• Extreme Programming and Agile Methods: Xp/Agile Universe 2002: Second Xp Universe and First Agile Universe Conference, Chicago, Il, USA, August 4-7, 2002: Proceedings (Lecture Notes in Computer Science, 2418), Laurie Williams, Don Wells, Friedrich Schiller, Springer Verlag, 2002.
• Extreme Programming Examined, Giancarlo Succi, Michele Marchesi, Addison-Wesley, 2001.
• Extreme Programming Explained: Embrace Change, Kent Beck, Addison-Wesley, 1999.
• Extreme Programming Explored, William C Wake, Addison-Wesley, 2001.
• Extreme Programming Installed, Ron Jeffries, Ann Anderson, Chet Hendrickson, Addison-Wesley, 2000.
• Extreme Programming in Practice, James Newkirk, Robert Martin, Addison-Wesley, 2001.
• Planning Extreme Programming, Kent Beck, Martin Fowler, Addison-Wesley, 2000.
• Test-Driven Development: By Example, Kent Beck, Addison-Wesley, 2002.
• The Capability Maturity Model: Guidelines for Improving the Software Process, Software Engineering Institute, Carnegie Mellon University, Addison-Wesley, 1995.
• The Pragmatic Programmer: From Journeyman to Master, Andrew Hunt David Thomas, Addison-Wesley, 1999.

Aberdeen Group

A six-part Insight series by Wayne Kernochan on the challenges and opportunities facing today's software development strategists. The following are titles and links:

• Developing the Enterprise's Software Portfolio: A Long-Term Strategy to Avoid "Software Sclerosis"www.aberdeen.com avoid software sclerosis
• Agile Programming, Extreme Programming, and Refactoring: Not Just Another Development Fad www.aberdeen.com agile
• Existing Application Upgrade Is Key to Future E-Business Strategies www.aberdeen.com upgrade
• Programmer Productivity Reconsidered: Reusability Considered Harmful - Refactoring Not www.aberdeen.com programmer productivity
• Software Quality: Test, Automate, Satisfice www.aberdeen.com software quality
• Design-Driven Development: Good Only If Done Wellwww.aberdeen.com design driven development

Web Resources for Extreme Programming

• Extreme Programming A Gentle Introduction: Provides an introduction and overview of extreme programming (XP). www.extremeprogramming.org
• XProgramming.com An Extreme Programming Resource: Offers downloads, articles and more. www.xprogramming.com
• PairProgramming.com An Extreme Programming Practice: PairProgramming.com houses articles and links to other sites discussing XP. www.pairprogramming.com
• Ward's Wiki Pages About Refactoring www.ward'swiki refactoring

SIDEBAR: Extreme Programming's 12 Core Practices

• Customers define application features with user stories.
• XP teams put small code releases into production early.
• XP teams use a common system of names and descriptions.
• Teams emphasize simply-written, object-oriented code that meets requirements.
• Designers write automated unit tests upfront and run them throughout the project.
• XP teams frequently revise and edit the overall code design, a process called refactoring.
• Programmers work side by side in pairs, continually seeing and discussing each other's code.
• All programmers have collective ownership of the code and the ability to change it.
• XP teams integrate code and release it to a repository every few hours and in no case hold on to it longer than a day.
• Programmers work only 40 hours per week; there's no overtime.
• A customer representative remains on-site throughout the development project.
• Programmers must follow a common coding standard so all the code in the system looks as if it was written by a single individual.

SIDEBAR: Sabre Takes Extreme Measures

Using extreme programming practices, Sabre Airline Solutions has reduced bugs and development times for its software products

By Gary Anthes

Saabre Airling Solutions had many years of experience with its AirFlite Profit Manager, a big modelling and forecasting package that many airlines use to wring more income out of flight schedules. Even so, Release 8 of the software was four months late in 2000 after final system testing turned up 300 bugs. The first customer found 26 more bugs in the first three days of its acceptance testing, and subsequent joint testing by Sabre and the customer uncovered an additional 200 defects.

"Our Sabre person on-site was as upset with the quality as the customer was," recalls Vinit Karandikar, a principal in Sabre's Airline Products Development group.

Sabre's experience with Release 8, which had almost 500,000 lines of code, isn't unusual. Software quality guru Watts Humphrey, a fellow at the Software Engineering Institute in Pittsburgh, estimates that commercial software typically ships with one to eight defects per 1000 lines of code.

But a lot has changed in the development labs of Sabre Airline Solutions, part of Sabre Holdings Corporation, a Texas-based, $US2 billion air-travel systems company. The software development firm has embraced extreme programming (XP), a controversial development framework in which testing precedes coding and programmers work in pairs. Sabre Airline Solutions has 62 software products with 13 million lines of code, and it claims that XP has dramatically boosted both the productivity of its 300 developers and the quality of their work.

For example, fewer than 10 bugs surfaced in Release 10 of its Profit Manager software in the two months after it began shipping to airlines in December 2002. Now, 16 months later, just 100 defects have been found. Release 10 was written in Java, while Release 8 was written in C and C++. But Sabre says it was XP, not Java, that produced the dramatic quality improvements.

And the initial benefits from developing better code may be eclipsed by long-term cost savings, Karandikar says. For Release 10, Sabre assigned just three developers to support 13 customers, while Release 8 required 13 people to support 12 customers.

The evidence is anecdotal so far, but there are enough anecdotes at Sabre to make a compelling case for XP. In another project, the company converted the user interface of its AirServ airline cabin provisioning optimization system from C++ to Java for the Web, a two-year effort that required rewriting about 100 graphical user interface programs. Programmer productivity jumped 42 percent - as measured by the number of labour hours required for each screen - after the development team switched to XP halfway through the project.

In yet another project, the Host Access Tool, which provides a common application programming interface for accessing legacy host systems and has 15,000 lines of code, was written from scratch using XP practices and has remained bug free in the 20 months since it shipped. Similarly, Sabre's Peripheral Manager, which manages interaction between host systems and peripheral devices, has 28,000 lines of code and has had just four bugs show up in 15 months.