Introduction

One of the most controversial aspects of Extreme Programming (XP), and of all the agile methods , is reduced focus on up-front design. While agile proponents generally do recommend doing some up-front design, the rapidity with which we turn to programming seems dangerous, even foolhardy, to people who dont understand or who have not yet tried what we teach.

For the past few years , Ive been experimenting with these ideas. I start with a very simple design idea and implement features in a customer-driven order, using refactoring to keep the design just barely sufficient to the moment. One question Ive been interested in was whether the code necessarily becomes brittle, hard to change, and unreliable or whether the process seems to be sustainable. Another key question has been whether more up-front planning and design would give better results, in terms of substantially less rework , faster progress, or a better resulting design.

My findings, for my work, are these:

• I can deliver features that the customer wants, at a consistent rate, over the course of the project.

• I make design improvements all the time, but mechanically they are more like additions and rearranging things, rather than like rework or redesign or starting over.

• I can keep the code clean and fit for its purpose, over the course of the whole project.

• I invest just as much in good infrastructure as I ever did, perhaps even more, but I make that investment over the course of the project, not just at the beginning.

• I deliver more function per unit time, embodied in code that I can be proud of.

This book is a chronicle of a little project done in the style XP recommends, insofar as Im capable of doing what I teach. The project includes many of the things that befall real projects: people leave the project and come back, new people come in for a while, key people get sick, hard problems crop up, and so on. We even get a difficult surprise requirement. To make it even more difficult, I chose a programming language and environment that I had never used before the start of the project, namely C# and Microsoft Visual Studio .NET.

Looking back over it now, Im amazed at how a one-person book project can look so much like larger real-life projects. The project is open to you. I share my thoughts, my mistakes, my little triumphs, and my code, good or bad. When I learn a lesson, for the first or hundredth time, I share it with you (typically in reader aids and sidebars).

For me, the bottom line remains that this approach works for me, and I can also report that its working well for most of the teams all over the world who are adopting Extreme Programming and agile software development practices.

For you, the opportunity in this book is to see how these practices work in the hands of an aging geek who is one of the most vocal proponents of these ideas. You can observe both what works and where I go off the rails. You can make your own decisions about how to fit the XP/agile ideas into your own development bag of tricks.

Code on the Companion Web Site

My intention in this book is to describe the thought and work practices that I use in creating a program and not to present here every line of code that went into the system. You might find value in being able to see all the code at various states through the project. The books Web page at http://www.microsoft.com/mspress/books/6777.asp includes several snapshots of all the code, taken at various points along the way. To access the code from the books Web page, click the Companion Content link in the More Information box on the page. This will load the Companion Content Web page, which includes a link to download the sample files.