Using Extreme Programming in a Maintenance Environment

Author(s): Charles Poole and Jan Willem Huisman
Venue: Software, IEEE. Volume 18, Issue 6
Date: 2001

Type of Experiement: Case Study
Sample Size: 36

Quality
3

Reference: http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=965801

SUMMARY
Using Extreme Programming in a Maintenance Environment studies the effects of transitioning a team of 36 workers from following poor, very individualized programming practices, to following extreme programming methodologies. Although not intending at first to adopt extreme programming per se, by trying to introduce the “best” practices in industry, Iona Technologies veered toward extreme programming methodologies without even expecting it. Once the company discovered the similarities between their newly acquired practices and extreme programming methodologies, the company actively adopted extreme programming to guide their own programming practices.

By the end of 1997, Iona Technologies had already patched and re-patched their system code (called Orbix) hundreds of times, increasing code entropy and decreasing program understandability. According to Kent Beck, “Maintenance is really the normal state of an XP project,” which is what Orbix had become. It was a rational choice, then, to adopt extreme programming.

Iona Technologies lacked a decent documentation process, and visibility was scarce in their current methodologies. Each engineer’s personal software practices were poor and widely varied, there was no focus on process improvement, and engineers reported not feeling cohesive in their software teams.

Programmers benefited when some paired programming guidelines were implemented, which improved collaboration and facilitated mentoring relationships. Additionally, other practices (even reorganizing the physical layout of office space) were implemented to increase communication and morale. Automation and optimization of test suites in 1999 also helped increase productivity and worker satisfaction. The company created builds on a nightly basis, cutting iteration time down drastically, and adopted a philosophy of “test before you implement, and test everything often.” In late 2000, the company hired a customer on-site to help promote productivity, which is noted as an extreme programming practice.

At the conclusion of the study there were fewer problems in new releases, a significant decrease in code entropy, reduced code complexity, and no patch rejections over the last few months of the study. However, metrics to effectively test these conclusions were not created, and so claims are based solely on comments from code reviewers. Overall, however, adopting extreme programming improved the team’s ability to deliver quality support and enhanced productivity.

The productivity measurement is based on a constant work force with no change in overall work habits in terms of hours spent fixing bugs, with an improvement of 67% over the previously employed practice. It was noted that improvements even continued when the team size was reduced in March 2001 from 36 to 25 workers.

One of the greatest success stories that this study boasts of is that of improvement in visibility. This was mentioned as “the greatest benefit to the team.” Visibility alone was a strong motivational factor in carrying out this study, in order to promote the number of issues people started to actively work on.

0