: Peter SchuhVenue
: Software, IEEE. Volume 18, Issue 6Date
: Nov.-Dec. 2001Type of Experiement
: Case StudySample Size
Recovery, Redemption, and Extreme Programming recounts the tale of a development project’s rejuvenation through extreme programming. A company called ThoughtWorks had a development team was tasked with creating a complex working system with a year’s worth of requirements in two months (due to slipping deadlines and more), and a client that, acknowledging that it had “switched horses midstream,” was willing to scale back on functionality – but refused to budge on delivery date. As a result, ThoughtWorks had to turn the project around and deliver a business-ready application in two short months. The application under construction was Web-enabled and powered by Enterprise Java Beans, but was constructed poorly. Possibly because of the problem’s sheer size and pervasiveness, ThoughtWorks was slow to realize how fundamentally bad things were, and realized too late. The team of developers worked all-nighters, hacking together code, working through weekends to complete the system, and inevitably commenting code with pleas such as “It’s 3:30 in the morning. Please forgive me” (this was found atop a 150-line switch statement).
The project was completed (barely on schedule), and after the delivery, the team manager negotiated with the client to allow time to apply “ease of maintenance” to the system – a clever euphemism for refactoring – so that the system could be redeemed. As it was, the members of the over-worked development team were embarrassed to have their names associated with the project. During this refactoring stage, extreme programming was adopted in order to “save” the system.
The switch to XP was a slow, unsteady process. Not all programmers welcomed the change, but eventually adopted the process. Refactoring code was first on the list, as mediocre code was improved upon when convenient and truly untenable code was rewritten. From a team wide perspective, the senior developers advocated JavaDoc as the unified coding standard, and unit tests were required for all refactored and added code. Email “advisories,” pick-up development discussions, and regularly scheduled code reviews helped increase communication and productivity on the project. The number of builds per day increased, and the number of broken builds plummeted.
The one insurmountable impediment that was encountered after the original product release was the client’s lack of cooperation. Without objecting to the shift, the client nonetheless refused to participate in the process in any meaningful way. Without any way to coax the customer into filling the extreme programming on-site customer role, the team’s project manager and analyst assumed the required role, writing story cards and providing domain knowledge on demand. Even so, the client’s absence negatively affected the team. Without a decision maker to sit in the same room with the team, the planning game could never be fully implemented, and “official” iterations were never shortened beyond being every three months – far too long a period for extreme programming practices.
Finally, as the system metamorphosed its infamy into high repute, junior developers took greater responsibility, and the team accepted new recruits. Good practices were passed along through pair programming, and extreme programming development gained more momentum. Although extreme programming wasn’t the team’s immediate salvation, it did, in the end, make the application sustainable. The gradual adoption of extreme programming “recovered, retooled, and rejuvenated the code base.”
The author proposes “phases” when different extreme programming practices should be adopted for similar situations. First, streamlining the build process is seen as key to an effective re-working of a system. The author notes that the simpler it is to perform a build—the less time it takes—the more likely it is that a developer will want to know that new code integrates successfully. Second, a test suite should be organized so that all new code can be verified to not break already existing systems. With these two phases in place, continuous integration and a “gentle” code refactoring can be gradually adopted. Time can then be spent simplifying code, and a coding standard can be adopted. Of course, throughout this entire process, an on-site customer is a great asset.
Although not an extreme programming “practice” per say, the author advocates stand-up meetings. Daily, face-to-face meetings keep developers and team leads informed, while preventing developers from stepping on each other’s toes and duplicating work. Iteration and small releases help boost productivity, even if they are only internal and not “official.” Finally, the rest of extreme programming’s twelve practices should be adopted in turn, all the while keeping communication between all members of the team, management, and customers, as open as possible.
This experience report concludes that extreme programming was successful on many levels for this project, and although the pure implementation of the agile process was never achieved, working toward full adoption helped the team along. Ultimately, though, the project’s redemption came to fruition not simply by following the processes drawn from extreme programming; the project was saved, too, only through the extreme efforts put forth by the “extraordinary” team that applied those processes.