Restoring the Craft of Software Development: A Review of Extreme Programming

Richard Pawson and Chris Woodward, CSC Research Services

Reprinted from the Winter 2002 issue of CSC World

The trendiest thing in systems development today is extreme programming. XP (not to be confused with the Microsoft product name) even has a range of branded accessories, from T-shirts to coffee mugs. Its proponents claim that XP delivers systems that meet the customer's requirements better, are delivered faster, and are easier to modify to meet future requirements. The first two claims are made by most forms of rapid application development; the last is unique.

XP in a nutshell

Software guru Kent Beck conceived XP, which has been fleshed out by other recognized experts, including Ward Cunningham and Martin Fowler. Beck believed there were four dimensions along which you could improve the effectiveness of any software development process:

• Simplicity of design
• Communication between all parties involved in the process
• Feedback, so you know you're going in the right direction
• Courage to do the right things, not just what some procedure tells you

Why another software development methodology?

Organizations have benefited from advances in the technology of systems development, but those benefits have been incremental and linear. One of the reasons why is that systems development has advanced far more in technology than in technique. XP is an attempt to introduce a qualitative change to programming techniques, to take the engineering out of software engineering and put the craft back in.

Many systems development methodologies have their roots in engineering. If you're building a digital telephone exchange, a satellite navigation system, or an e-commerce engine that must handle thousands of transactions a second, the discipline of engineering is what you need. But for the vast majority of business systems, those disciplines, with their emphasis on sign-offs and sequential activities, simply get in the way.

Not everyone sees the value of "craft" as an alternative metaphor for programming, however. For many people, the word conjures up images of the entertaining and nostalgic "traditional crafts fair" — quaint but impractical. Others see the idea of programming as a craft merely as an excuse for fast-and-loose work that is unreliable, undocumented, and un-maintainable.

For another perspective on this alternative metaphor, think of the practical crafts associated with house-building, such as carpentry, bricklaying, plastering and plumbing. These crafts employ considerable discipline, but that discipline does not depend upon formal procedures and processes, nor upon abstract formal learning. The discipline lies in the use of patterns.

Mastering crafts by learning patterns

Learning to be a good carpenter is about learning the patterns of good carpentry, from the micro patterns such as how to cross-nail a joint to the macro patterns of a roof structure. These patterns have names (purlin, king-post, wall-plate), and the names do more than just provide a convenient reference to a specific piece of timber: They help to reinforce the structural patterns necessary for sound roof structure.

The idea of patterns in programming has recently become far more explicit. In fact, several of the main proponents of XP were instrumental in the development of the pattern-based programming movement. In traditional crafts, patterns are learned through apprenticeship, and there is a growing call for some kind of apprenticeship model for systems development. Pairing a junior programmer with a senior programmer is one way to achieve the knowledge transfer. (This is not paired programming, which is intended to provide peer-level code reviewing between two competent and experienced programmers.)

Empowering programmers

Most systems development managers recognize that their best programmers are at least 10 times as productive as their worst. New technologies are probably widening the gap. One can argue that XP is really a mechanism for empowering your more capable programmers.

Many systems development methodologies are oriented to the least capable programmers. XP is oriented to the most capable. It is this fact that gives XP a certain cachet. More than one organization has recognized that allowing its better developers to practice XP, and to be seen to be practicing XP, is, if nothing else, a positive motivator.

Empowerment is often linked with disintermediation. XP effectively disintermediates systems analysts by bringing the system's customers into direct contact with programmers. In XP's early days, its proponents believed (somewhat naively) that a programming team needed only a single user to represent all requirements. As XP has grown, practitioners have had to address the complexities of multiple stakeholders and types of users.

Today, it is common to have a kind of user proxy. This person may have a systems background, but the role of user proxy is not defined by a particular process skill (as is the case with a systems analyst). It is defined instead by an intimate knowledge of the business domain, by relationships with a broad range of potential users, and by the trust of the users that their needs will be represented accurately.

Creating an environment for XP

The best way to find out if XP is suitable for your organization, or indeed if your organization is up to the task, is to try it out. Be aware, though, that success with XP demands courage not just on the part of developers, but on the part of management. XP demands a "skunkworks" approach that gives organizational freedom for programmers to define their own rules within a small set of constraints. The most important factors in the environment are not physical — they're managerial and cultural.

Twelve practices that define extreme programming

Simplicity

Small releases. Software is delivered in releases, typically between one and three months long. Each release is made up of iterations delivering a subgroup of user stories and typically lasting from one to three weeks - a standard time window is set and used throughout the project.

Simple design. Anticipating future requirements is wasteful. Develop only the software needed to meet the requirements scheduled for the current iteration.

Feedback

Continuous integration. Integration typically occurs many times a day in a serial fashion, and is carried out by the programmers who deliver the new or modified program(s).

Paired Programming. A pair of programmers are in constant discussion with each other as they perform each task. One "drives" and handles the keyboard, while the other observes and suggests alternative solutions. Programmers often switch roles. Pairings change from task to task.

Test-first coding. Programming proceeds as a series of short "code-the- test" followed by "code-the-solution" steps. One automated unit test is created to define a small aspect of the requirement, then the simplest code is written that passes the test, and so on.

Courage

Forty-hour week. Overtime is counterproductive. Instead, reduce the scope of what is to be delivered through release and iteration planning.

Merciless refactoring. Refactoring improves a program — by removing redundancy, eliminating unused functionality, and rejuvenating obsolete designs — without altering its external behavior.

Communication

On-site users. On-site users communicate their requirements directly to programmers. These requirements — one-to-three-sentence summaries known as user stories — are small enough to be implemented within one development iteration.

Collective code-ownership. The team shares responsibility for all of the code. As a programming pair works on a task, it develops new code and changes others' code by refactoring and by accommodating new requirements.

Coding standards. Enforcing good coding standards supports the collective ownership of software and effective communication between team members.

Commitment planning. Users and programmers jointly plan each iteration. Users decide on the stories to be developed. Programmers estimate the effort needed to deliver each story, then sign up for tasks and programmer pairings.

System metaphor. Choose a metaphor for the system being developed (e.g., a production-line metaphor for a payroll system). This allows the team to give consistent names to elements, and promotes understanding of how the system works without having to acquire specific knowledge about it.

Related Information:

Contact Us and Let Our Experience Help You Produce Results.

Learn more about CSC Research Services.