eXtreme .NET: Introducing eXtreme Programming Techniques to .NET Developers [Electronic resources] نسخه متنی

One Small Step at a Time

Something that always seems to amaze even the most experienced developers is how small each step in an eXtreme Programming development cycle actually is. At the beginning of 1993, I worked on a C++ project with a team of developers. We did not use XP, but we did use a set of rapid development practices.

The team would take a part of the specification and break it up into small pieces of work. Each of these tasks was estimated to take at most half a day. We listed the tasks on a whiteboard. We compiled the entire system after each task was completed and checked the code into the source control system we were using.

At that time, none of us had heard of unit testing, and the view was that if it compiled then that allowed us to move forward. Every day one of us would run the entire system and manually put it through its paces to check it was working as expected. There were, of course, a few issues, and they became more tasks on the whiteboard.

Because the team was doing well, we recruited a couple of new developers to the team. One of these developers taught us all a very important lesson. The day he started, he read through a section of the specification and then set about coding it. After a week, he declared he was done. I thought that was pretty good until he told us that now he was "ready to compile the code." I was stunned. Did that mean he had written code for a whole week without knowing whether any of it compiled? I wasn't sure I had heard him correctly. I double-checked. Yes, he had written code for a week without doing one compilation.

He compiled it and proudly told us that he only had 197 errors and that he would start getting them fixed up right away. I was still stunned and not sure what to say. A week later and the poor chap was still struggling with a high volume of errors and warnings. He worked hard trying to get the code to work. I tried to sit down and help him, but his ego wouldn't let any help come his way.

In the meantime, the rest of us were working our way through the tasks on the whiteboard one at a time. Another week went by. Although there were certainly fewer errors, our new team member still hadn't managed to get his code to fully compile, let alone work. Needless to say, he didn't last much longer with the team. He had wasted four man weeks of work and had nothing to show for it. The interesting thing was that in the first week or so, the managers thought this new developer was the "best thing since sliced bread." He had just sat quietly at his desk for long hours each day coding away (while the rest of us were constantly talking and making noise and never worked longer than nine hour days). The manager's change in opinion occurred when we showed what we had been delivering and had to explain that the code written by our new friend in the past three weeks had not been included because it broke the system.

Hopefully, the lesson that team learned in 1993 you don't have to learn the hard way.