The Coad Letter: Modeling and Design, Issue 112, The Contributions of Extreme Programming, by Granville Miller

By: Coad Letter Modeling Editor

Abstract: Ward Cunningham and Kent Beck created an agile software development process that questions the core of software engineering. As a result, software development will never be the same.

Every industry looks for new ways to increase its productivity. Software development is no exception. The recent wave of agile software development processes seek to emphasize the value of individuals, collaboration, working software, and responding to change. At the forefront of these agile software development processes is Extreme Programming (XP). While there are many other agile processes in the software development arena, none is more highly publicized. The reason that this process gets so much attention is more than just its catchy name. It has presented a serious challenge to the traditional way that we create software.

A Back-Loaded Process

Software development processes have evolved over the past forty years to become much more than just writing code. Requirements engineering has become a virtual science where different requirements artifacts are used to capture what the system should do. Analysis and design utilize modeling to decompose the domain and map it to the computer. In many software development processes, it is only after we finish this work that we can begin coding and then testing.

We can divide the software development process into two stages. The first stage involves deciding what the system will do and how it will do it. The second stage involves implementing a solution. In front-loaded processes, we spend the majority of our time in the first stage. In back-loaded processes, we spend more time in implementation. There are, of course, obvious benefits with spending time in each area.

However, in front-loaded processes, we often hear that implementation is easy because all of the thought is performed up front. Back-loaded processes were often considered chaotic and uncontrolled. Traditional software development favors the front-loaded process because they appear to under control at all times. We simply follow a well thoughtout plan to deliver our system. Then XP came along. While XP was initially dismissed as hacking, careful examination shows that XP is a back-loaded process with as much control as any front-loaded process.

Test-Driven Development

One of the ways that XP exerts its control is to utilize some innovative techniques and to change the order of certain activities. In the past, unit tests were written to test existing code. However, XP changed the order of the implementation and unit testing activities to place testing first. In other words, we write a test to describe what the code should do before we write the code. This is true coding with intention.

XP requires that we write a unit test whenever we are going to implement a given task. First, you implement the unit test and run it to ensure that it fails. Then you write only the code necessary to make the unit test succeed. Once you have implemented the code, you run all of the unit tests for the project to make sure that you have not only implemented your task but also have not broken anyone elses code. These unit tests give us the courage to make the changes necessary to make rapid advances.

XP did not act in isolation to deliver these new ideas. Technological advances also made this metamorphosis possible. Modern integrated development environments (IDEs) support the ability to compile systems incrementally and to perform these unit tests quickly. In fact, most IDEs now contain built-in unit testing capabilities. However, XP was the first software development process to take advantage of these changes.


Another area where extreme programming changed the traditional software development rules is design. XP focuses less on getting the design right up front and more on refactoring the code to express an emergent design. This is because XP looks at design as a communication vehicle to express the implementers intent. Design is viewed as a way to eliminate duplicate code. Thus, design emerges as part of the implementation effort.

The primary vehicle for creating good designs is through refactoring. For those new to this technique, refactoring is a set of well defined code transformations that make the code more elegant. This eases the effort required to read the code and makes the code base more maintainable. Refactoring was always (or should have always been) an implicit part of the coding process. XP made it explicit. The design strategy for XP is to design through continuous refactoring. Commonality is removed from the code base by modifying the code.

Refactoring is an activity performed during implementation that recognizes the value of iteration in building systems. Instead of trying to understand everything up front, we learn while building the software. We get things wrong before we get them right. Like unit testing, refactoring is also a part of many of today's IDEs.

Pair Programming

In traditional software processes, reviews were used to discover various kinds of coding mistakes. Often, another pair of eyes can help us write better code. XP took this idea to the extreme. Instead of getting feedback at the end of the iteration, why not get this form of feedback continuously? The result was the addition of pair programming, having two people work on a task instead of one.

Pair programming seems like it would cause a reduction in productivity. However, studies have concluded that you get twice as much done when you are working together. Changing the people who work together fosters communication between memebers of the group. It also develops a common set of skills. However, the greatest feature of pair programming is the improved quality of the resulting system.


Extreme Programming serves the software development community in many ways. It provides a popular agile software development process that will make many projects successful that otherwise might not have been. It has boosted the morale of many projects so much so that many of its proponents are vocal in their desire to continue using it. But more than any of these factors is the fact that it has made a profound impact on the way that we view building software. This will be its legacy, one successful project at a time.


[Astels 2002] Astels, David, Granville Miller, and Miroslav Novak. A Practical Guide to eXtreme Programming, Prentice Hall 2002.

[Miller 2001] Miller, Granville. Sizing Up Today's Lightweight Software Processes, IEEE IT Professional, May/June 2001 p.46-49.

Server Response from: ETNASC04