In the beginning, I just wrote code. I programmed in BASIC and then in 6502 assembler. Then I learned C, 8086 assembler, and then Pascal. I started to understand some of the issues involved with functional programming and then procedural-based development. Most of the projects I did were small, achievable by me or with just one other programmer. The communication channels were limited, and we got software shipped. I was often a guy alone in a room.^[1] My bosses at the time often let me work from home or on my own hours. Often I would start early, have a long lunch, take a nap in the afternoon, and then program until midnight. Life was good, and I worked on some really cool software. Some of this software still ships.

Then in 1991, I joined my fist big software team; there were five of us! I was the last to join the team. The project was already in full swing, and it was chaos. I was confused, afraid, sad, and mad all at the same time. The code in the source-code control database didn’t all compile. There was no standard coding convention; each programmer coded with a different style. There was no form of testing. We had no idea when the system would be finished. The tasks were handed down to me as I finished the previous one. I had very little idea where I was going. We were programming in C++, and this was only my second C++ project. I was afraid that the lack of object-oriented (OO) programming in the project meant that I did not understand what OO was really about. One month after joining the team, I started to raise these issues. There was a lot of struggle and internal debate, especially about the little things such as where the curly braces should go!

Eventually we got the system in a state where the code all looked pretty much the same. We reached a point where we could compile the entire code base every night. I was realizing the importance of development practices to the team.

For a few years, I worked with a couple of teams. I helped these teams implement what I considered to be crucial aspects of the development process. In 1995, I became involved in my first start-up company. All the developers were younger than I, and by virtue of my age I was looked up to as the leader. At the same time, some interesting books were published on the development process. Notable books for me were Jim McCarthy’s Dynamics of Software Development (Microsoft Press, 1995) and Steve McConnell’s two books, Code Complete (Microsoft Press, 1993) and Rapid Development (Microsoft Press, 1996) They were inspiring; they made me realize I wasn’t the only person struggling with these issues and that there were better ways to develop software. What’s more, they were written by guys at Microsoft, one of the world’s biggest software companies. Their strategies made even more sense to us because we were using the Visual C++ development tools, and Jim McCarthy’s team wrote those tools. Well, if we could do as good a job as them, we would be okay.

That first start-up company didn’t make it. We ran out of funding, and there was no real marketing effort. It was a shame we had written some excellent code that would never ship. The next step was to start up on our own. Six of us from the failed start-up banded together and decided to break out on our own. We had learned a lot of lessons, including that we needed to learn more.

Four years later, at that second start-up, someone discovered XP. It was 1999, and the dot.com buzz was in full effect. This company was delivering traditional C++ applications for the Windows desktop, using back-end databases and middle-tier COM business objects. The world had changed, and XP looked like it would help us keep up. I was intrigued, and never being far from the code, I tried some pair programming. It was fun. I bought a few copies of Kent Beck’s book Extreme Programming Explained (Addison-Wesley, 1999) and handed them around. I worked with the team on task breakdowns. We built test frameworks and tried test-first programming. We had morning stand-up meetings to discuss progress and work out our strategy for the day. The interesting thing was that it didn’t seem a very big jump from the rapid application development approaches that were introduced in the McCarthy and McConnell books.

We managed to complete a lot of work and have fun at the same time. The quality of our code also improved dramatically. The last project I worked on with this team shipped ahead of schedule and has never had any bug reports from customers. I believed I had to tell other people about what we were doing.

I had a stake in another company at that time. It was being engaged to develop some early-stage software using early versions of the .NET Framework. Much of the framework was pre beta and very flaky. I suggested they use an XP approach to help them learn the tools and protect themselves from incorrect assumptions. This worked well. I investigated further and found another company in London that was using XP. They were also doing very well. It seemed like a great way to develop software. That year I ran three courses on developing software using XP practices. The teams I worked with did a great job, and a year later I felt ready to retire. The 1990s were good to me.

A year and lot of adventures later, I found myself in Australia looking for companies that were using XP. I wanted to teach and code again. I was a believer, and I wanted to work with others who knew the “way” to develop software. Yes, I wanted to write code; it is what I do, I enjoy it. I love the creative aspect of software development. I love the purity of that creation. A Russian I once worked with used to say, “Hey, this is software; you can do anything if you have enough money.” I believe he was right.

I formed the Sydney XP Activity Club (known as SyXPAC) and started teaching groups about the joys of XP. At the same time, Microsoft was getting ready to release the .NET Framework and the Visual Studio.NET development environment. I found myself working with the two together. I introduced them together in a course I started running called XP Techniques for .NET Developers. The result has been the creation of a number of eXtreme .NET development teams. Much of the material in this book comes from the lessons learned on those courses and the mentoring I have been doing with development teams.