Extreme Programming

Computerworld - Oftentimes, the little things can make the biggest difference. Consider some of the tenets of a new programming approach: keep the code simple, review it frequently, test early and often, and work a 40-hour week.

Programmer Kent Beck developed extreme programming (XP) while serving as project leader on Chrysler Comprehensive Compensation (C3), a long-term project to rewrite Chrysler Corp.'s payroll application. Beck then spelled out the development methodology in a book titled Extreme Programming Explained: Embrace Change (Addison-Wesley, 1999).

XP’s 12 Core Practices 1 Customers define application features with user stories. 2 XP teams put small code releases into production early. 3 XP teams use a common system of names and descriptions. 4 Teams emphasize simply-written, object-oriented code that meets requirements. 5 Designers write automated unit tests upfront and run them throughout the project. 6 XP teams frequently revise and edit the overall code design, a process called refactoring. 7 Programmers work side by side in pairs, continually seeing and discussing each other’s code. 8 All programmers have collective ownership of the code and the ability to change it. 9 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. 10 Programmers work only 40 hours per week; there’s no overtime. 11 A customer representative remains on-site throughout the development project. 12 Programmers must follow a common coding standard so all the code in the system looks as if it was written by a single individual.

Since then, advocates of XP have cropped up like kudzu and sparked a maelstrom of debate among programmers and project managers who either love or love to hate its ideas.

According to Beck, XP is a lightweight methodology, meaning that it dispenses with much of the usual application development process, such as lengthy requirements definition and extensive documentation, and that it emphasizes keeping development teams small and the code simple.

Instead of creating large functional-requirements documents, an XP project begins by having the end users of the software create user stories describing what the new applications need to do. Functional testing of requirements is done before any coding begins, and automated testing of the code is done throughout the project. "Refactoring"—the frequent streamlining of design and improving of code—is also a core doctrine.