Launching Extreme Programming at a Process-Intensive Company

Author(s): James Grenning
Venue: Software, IEEE
Date: 2001

Type of Experiement: Case Study
Sample Size: 3



Using Extreme Programming in a Maintenance Environment is a case study describing the entire process of adopting extreme programming in a company in a very small team of two software developers – from initial acceptance to almost-final software product – and discusses the benefits and drawbacks of this software process when building safety-critical software.
The author describes the process that was used to propose extreme programming to management staff, how the project seed began and grew, and some of the issues the team faced during its first six months. The initial proposal was sparked due to current company processes not catching enough bugs, yet adding excessive overhead for all workers. Unrealistic deadlines and surprises late in projects also plagued DSP (a fictitious name given to the company being studied), causing deadlines to slip and the burnout of good engineers.

The current processes of DSP were front-loaded with design and documentation, so getting extreme programming with its product features written on note cards and having code be design, was not an easy task. For this environment, management would never allow all extreme programming practices to be implemented all at once. Some aspects of extreme programming had to be omitted, but not due to preference – due to management – so the author tried as many as were allowed. The extreme programming processes that were employed were small releases, simple design, functional testing, test-first design, refactoring, pair programming, collective code ownership, continuous integration, 40-hour week (sustainable pace), and adhering to a coding standard. Other extreme programming practices were not used at all, or only partially adopted and/or modified.

The team was comprised of three people—a customer (the company’s system engineer), and two developers, including the author. Extreme programming gave the developers on this team “confidence” in their programming, as working test-first led to reduced coupling, paired programming helped efficiency and promoted learning, and defects could be remedied quickly due to short iteration cycles. The author describes that the mentality for developing became one of creating the best design for the information known at a given moment, instead of trying to pinpoint the best design “of all time,” which created a more relaxed environment in which to work. Paired programming, although enjoyable and helpful, also served as the most severe setback for the team, due to the fact that the team itself was only a pair.

The team benefited greatly using extreme programming, but marketing needs changed, and the project was abandoned. Even so, it should be noted that the managers of this extreme programming duo were very impressed with the increased productivity (a semi-working prototype was created in the same amount of time it took to produce three requirements documents using traditional DSP processes) and the programmers themselves commented on the increase of quality of their code while following extreme programming guidelines.