Establishing Best Practices
Sabre Airline Solutions adopted XP in 2001. With its new model, Sabre does iterative development in small, simple steps. The company uses two-week iterations, and customers see a new release every one to three months. Features, called "stories", are expressed in user terms and must be simple enough to be coded, tested and integrated in two weeks or less.
Automated unit tests (against the programmer's criteria) and broader acceptance tests (against customer requirements) must be passed at the end of each iteration before the next can begin. Unit and acceptance tests for each feature are written before the feature is coded. If a developer has trouble writing a test, he doesn't clearly understand the feature.
Actual coding is done in pairs by teams in open labs, promoting collective ownership of code, although individuals sometimes do the simplest tasks. Programmers are re-paired frequently, often every day or two. They sign up for the tasks they want to do and the person they want to pair with.
Every project team has an "XP coach" and an application subject-matter expert called the XP customer. The XP customer stays in or near the programming lab all or most of the time. He decides on and prioritizes product features, writes the stories for programmers and signs off on the results.
Refactoring code - rewriting it not to fix bugs or add features but to make it less redundant and more maintainable - is strongly encouraged. Sabre says the concept hardly existed at the company before XP because it was too difficult.
Finally, simplicity is paramount. The simplest things are done first, and code is never made more complicated in order to accommodate an anticipated future need that may never materialize.
Brad Jensen, senior vice president for airline product development at Sabre, says the quality improvements come largely from XP's continuous testing and integration. "Every two weeks what you've completed has got to be production-ready," he says. "You code as you test. You actually write an automated unit test before you code the unit, so if bugs do creep in, you find out about it right then."
Damon Hougland, director of airline products and services, says pair programming is hard for some to swallow at first because it suggests that programming costs will double. But the method actually reduces cost, he says, because the extra time it takes to write a line of code is more than offset by the reduced effort required for testing, fixing bugs and maintaining the code.
And, because at least two people know every chunk of software, and because Sabre reassigns and re-pairs people frequently, there is always a backup on hand. "Everyone on the team works on every part of the system," Hougland says. "You have the weaker people paired with the stronger people, and business knowledge and coding knowledge are transferred very quickly."
XP doesn't encompass all the practices that a software development organization should follow, Hougland says. "XP really focuses on what [programmers] do," he says. "It doesn't cover the traditional project management you have to do with customers, such as customer communications, and a lot of the testing we do is not covered in XP. A lot of people try XP and fail because they assume that XP will do everything for a development methodology."
Sabre doesn't yet follow XP 100 percent. XP doctrine says that both unit tests and acceptance tests should be automated. Unit tests at Sabre are conducted with the open-source JUnit testing tool, but many of the more complex acceptance tests are conducted with manual scripts. "We've struggled to automate them, and we have made some progress," Hougland says.
Jensen compares XP to the Capability Maturity Model for Software, saying XP covers many SW-CMM practices. The difference, he says, is that CMM tells organizations what they should do while XP is more oriented to saying how to do those things. "CMM is all about management processes; it's less about technical processes, the techniques of coding," says Jensen.
Jensen, who sponsored the adoption of XP at Sabre Airline Solutions, says he considered using other so-called agile programming methods, such as Agile RUP, a version of IBM's Rational Unified Process; Scrum, an iterative, user-oriented methodology; and Feature-Driven Development. "None of them are as fully developed as XP," he says.
Jensen says he especially likes XP metrics because they come in user terminology rather than the technical jargon of some methodologies. "With XP, we are checking off features and stories that I can understand like a business person," he says. "There's a lot of increased communication between the customer and the development team because everything that's being prioritized is in terms the user can understand."
Jensen acknowledges that his developers deviate somewhat from pure XP practices. Sometimes the XP customer has to travel and can't be in his lab full-time, as XP doctrine demands; refactoring old legacy code can be extremely difficult; testing isn't as fully automated as XP would have it; and acute deadline pressure from customers can lead to cutting corners.
But when asked if he has reservations about any of the 12 core XP practices, Jensen says: "They are all good practices. The only thing you could possibly argue is whether you really can afford to do all of them all the time. But if there's any compromising, it's not intentional."
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.