Seven years ago, in the midst of a global IT boom, programming shops of all shapes and sizes were racing like mad toward the next IPO, and the job market was hotter than ever. I had been pulled into the booming new media industry and was just starting my programming career, spending long days and nights hacking away at random pieces of code, configuring servers, uploading PHP scripts to a live production system, and generally acting like I knew my stuff.

On a rainy September evening, working late again, my heart suddenly skipped a beat: What did I just do? Did I drop all the data from the production database? That’s what it looked like, and I was going to get canned. How could I get the data back? I had thought it was the test database. This couldn’t be happening to me! But it was.

I didn’t get fired the next morning, largely because it turned out the customer didn’t care about the data I’d squashed. And it seemed everyone else was doing the same thing—it could have been any one of us, they said. I had learned a lesson, however, and that evening marked the beginning of my journey toward a more responsible, reliable way of developing software.

A couple of years later, I was working for a large multinational consulting company, developing applications and backend systems for other large corporations. I’d learned a lot during my short career, thanks to all those late nights at the computer, and working on these kinds of systems was a good chance to sharpen my skills in practice. Again, I thought I knew my stuff well when I joined the ranks. And again, it turned out I didn’t know as much as I thought. I continued to learn something important almost every day.

The most important discovery I made changed the way I thought about software development: Extreme Programming (XP) gave me a new perspective on the right way to develop software. What I saw in XP was a combination of the high productivity of my past hack-a-thons and a systematic, disciplined way to work. In addition to the fact that XP projects bring the development team closer to the customer, the single biggest idea that struck a chord with me was test-driven development (TDD). The simple idea of writing tests before the code demolished my concept of programming and unit-testing as separate activities.

TDD wasn’t a walk in the park. Every now and then, I’d decide to write tests first. For a while, it would work; but after half an hour I’d find myself editing production code without a failing test. Over time, my ability to stick with the test-first programming improved, and I was able to go a whole day without falling back on my old habits. But then I stumbled across a piece of code that didn’t bend enough to my skills. I was coming to grips with how it should be done but didn’t yet have all the tricks up my sleeve. I didn’t know how to do it the smart way, and frequently I wasn’t determined enough to do it the hard way. It took several years to master all the tricks, learn all the tools, and get where I am now.

I wrote this book so you don’t have to crawl over the same obstacles I did; you can use the book to guide your way more easily through these lessons. For me, catching the test-first bug has been the single most important influence on how I approach my work and see programming—just as getting into agile methods changed the way I think about software development.

I hope you’ll catch the bug, too.