This article was written over a six month period as an exercise to witness the benefits of extreme programming over time in a real world environment.
The practice of XP in our group began in December of 1999. At that time our team consisted of three C++ developers. We were fortunate in that the product was a Version 1 software application, that meant the legacy code wasn’t too extensive, about 90,000 lines, and it was approximately one year old (the design began in May of 1998, followed by a R&D period, then the foundation for our legacy code began).
Unfortunately, that legacy code was done the old fashion way: Lightning fast, by each developer sitting alone at his desk with headphones. The environment in which this software was being created, was probably typical of most Internet startups, getting first to market was as important, if not more, than having the best software in its category.
By December of 1999, or small Internet startup was growing quickly. Developers were joining the company weekly, and we needed an lightweight method of ensuring a high quality product, without being too overloaded with processes. It was after this initial phase from small R&D project into a sellable and marketable application that we investigated ways to improve our development process.
First, I read about XP in the pages of C++ Report magazine. Then editor of the defunct magazine, Robert Martin, mentioned XP in his editorial of October 1999, “I like the attitude of these processes. They depend heavily upon the creative input of people rather than the dictatorial pronouncements of a document”. I was intrigued. Having previously worked in a UML heavy environment at my previous employer, I related to his words. I felt stifled when I had to express myself using UML notation, I was much more at ease writing the C++ pseudo code on the board when attempting to convey a sense of program flow to my teammates.
Also that month, Kent Beck published a paper in Computer entitled “Embracing Change with Extreme Programming”. I distributed photocopies of that IEEE article to the other two developers on my team. I had looked at other processes, frameworks and tools. It was clear to me that what was needed was a process which was lightweight. Being an new Internet App meant we needed to be able to produce a lot of code quickly, without being weighted down by a process with high overhead.
Following this XP introduction, I attended C++ World in Miami in December. I attended a session on XP by Robert Martin, and it was then that my mind was made up, I was going to formally request our team adopt XP as a process. After all, we had approximately two months ahead of us to release our subsequent product version.
After the go-ahead meeting, Kent Beck’s Extreme Programming Explained book was purchased for everybody on the team. We determined who our ‘customer’ was, in our case the product manager. He would be the one to ensure new features were done in the correct order.
Our initial focus was on three key points: Pair programming, test cases, and reviews. The first hurdle was the logistics. Some desks were arranged for one person only, some desks were in corner’s and could not accommodate more than one developer at a time. To pair programming, it is necessary for the keyboard to freely flow from one person to another. To reduce the overall furniture re-arrangement, we simply pair programmed at each other’s desk.
The next hurdle was to be expected with such a small team. At times when I needed to program, one or both of my co-workers would be interviewing a candidate, or would otherwise be in a design meeting! To avoid this, we scheduled job interviews and design meetings outside peak development hours.
One of the more interesting aspects of XP. feature stories, were not going to be used in this time frame. There was simply not enough time between December and February to implement major features. Nevertheless, our ‘customer’ helped us greatly in determining which bugs to fix first.
XP payoff came quickly. The very first pair programming task was a test application to test some of the networking functionality of our application. That stand-alone app was completed in about two days by two developers, but the time it saved afterwards was enormous. We were refactoring much of the code which we felt was weakest from v1.0 and each time we made significant changes we ran the test app. Each time we checked-in these changes we felt very comfortable since we knew the test applet was run at every iteration. XP was earning a reputation quickly around the office, and our team was sometimes envied!
As our original team of three grew to five, we continued to develop the XP way. The first book newcomers were given to read was Kent Beck’s Extreme Programming Explained. Any opposition to this concept remained absent, even after two months. We kept with our original objectives: pair-program new code and write unit tests for it. It was clear that this was paying off. Whereas originally we would have to review our peer’s work, we now opted to sit with him during the coding phase. This allowed the more seasoned C++ developers to help the newer developers. The new developers became more productive quicker. I remembered the days when I began, and how much time I had spent alone, trying to resolve a particularly difficult problem.
After 2 months the initial XP shock wave had passed leaving behind a well established software development practice: tests, pair programming, and refactoring. It was surprising to me to see how quickly those practices were accepted. No one complained, code was being produced at the same rate, (because less time was spent debugging) and it was of higher quality overall. The code wasn’t the only thing improving, the team grew to know one another, and there were never any serious disagreements.
Our offices in the new building were to be constructed with XP in mind. We were to each have our own independent office, with one room for 6-8 people to be used as a development lab.
After the 1.1 release, we moved into new offices. We had asked for an open space where we could pair program, with personal offices where we could retire for some peace and quiet. When the development team moved into the new offices, pair programming was clearly not taken into consideration. Although the offices were all new and well equipped, pair programming was more difficult than ever. It was a case of form before functionality. Somehow our demands got lost in the transition. It is unclear if this was caused by insufficiently expressing our demands, or if the teams demands were refused. Kent Beck describes the importance of office space,
"Taking control of the physical environment sends a powerful message to the team. They are not going to let irrational opposing interests in the organization get in the way of success. Taking control of their physical environment is the first step toward taking control of how they work overall."
We settled in, and as the deadline for our next release drew closer, we forgot the little things that make XP so beneficial and slowly reverted back to the traditional software development process. The team of three who originally adopted the XP strategy was now a team of nine developers, in addition to the two product managers. What used to be pair programming became code reviews. Then code reviews grew scarce, time was too valuable a commodity.
Were it not for the quality people here, the product quality could have suffered. Although pair programming was essentially nonexistent, other aspects of XP were followed. One of the things we were not afraid of doing was to refactor old code. I could spent an entire day rewriting 600 lines of existing code into 250 lines of refactored code. There was a general sense that a module would get refactored over time, that no piece of code was beyond the reach of our refactoring abilities.
In addition to refactoring, the other key component held over from xp was unit tests. As the team grew, we even had the privilege of having two code qa developers writing unit tests! I greatly enjoyed the time where a separate pair of eyes would go through my code and its tests, reformatting it according to our coding standards, and write additional tests if required.
After refactoring and unit tests, the third most beneficial aspect was continuous integration. We had daily builds which were given to QA for daily smoke tests.
These three XP facets; refactoring, unit tests, and daily smoke tests, allowed us to continue and produce high quality software. Some would argue, and I agree, this does not constitute Extreme Programming. Why is pair programming so important? Kent Beck describes the importance of pair programming,
"Another powerful feature of pair programming is that some of the practices wouldn't work without it. Under stress, people revert. They will skip writing tests. They will put off refactoring. They will avoid integrating. With your partner watching, though, chances are that even if you feel like blowing off one of these practices, your partner won't."
After nine months, I cannot say our team uses XP. This is not a scar for XP as much as it is a comment on the state of software development. For XP to succeed, it must be continually practiced, it must be used by all team members without exception. Finally, just as important, XP must be accepted by management as well. For XP to succeed within an enterprise, it requires that company to change its perception on how software is built.