Building Test-Driven Developers
J.B Rainberger (I still know him as Joey) is a long-time friend who ended up getting involved in testing just as I did but had a much different path. I asked him for his thoughts on the people part of testing.
It’s funny how life works. I met Chris in 1988 and it had nothing to do with software. I was 14, we were both baseball fans, we both grew up near Toronto, and we ended up connected by (of all things) a board game. A baseball board game. An unbelievably geeky baseball board game. We played in the same circles for several years, but our relationship remained exclusively about baseball. And then he left our little club before we’d ever had a chance to talk about software. How could we? I didn’t become a professional programmer for almost another decade.
Fast forward to 1999 when, sitting at a non-descript desk at IBM, annoyed at programming myself into yet another corner, I typed “how to test java code” into Netscape Communicator 3 pointed at altavista.com. This led me to JUnit, and then to Extreme Programming, and the rest is history. I had no idea that Chris was about to go through a similar experience across town.
The universe decided that we should find each other again. It happened to be Twitter, but it was bound to happen. You see, Chris is to the PHP world what I once was to the Java world. Of course, Chris has my marketing department beat, so long after history forgets about me being “the JUnit guy”, it’ll remember Chris as the Grumpy Programmer. Good! Chris has engaged a community about a topic that, almost 20 years later, still really matters to me: encouraging programmers to develop habits that make everyone more confident about the quality of their work. For me, one word stands out in that sentence: habits.
Kent Beck once called himself a decent programmer with excellent habits. This idea drew me in instantly (I can do that!) and it has served me well. I work with less stress, more certainty, and greater ease. It feels great! If you’re reading this, then that probably sounds good to you, too. This book goes beyond the superficial into the more interesting aspects of programmer testing: the obvious “why” and the deeper “why”s. Sure, it talks about why programmers should write tests and how those tests help, but it goes beyond that into why programmers don’t already write tests and why the larger project community often resists this vital work. On the one hand it saddens me that we should need another book on this topic, but on the other hand I feel good knowing that Chris has stepped forward to share his views. This book will help both the experienced programmers who need better habits and the new programmers who don’t need to make all the same mistakes that we made.
Why does programmer testing still matter? It’s simple: in times of great stress, when people panic, they fall back on their training. Wouldn’t you rather programmers fall back on great habits instead of panicking and taking avoidable risks with your project or worse, your money? Wouldn’t you rather feel confident and relaxed while the people around you are panicking? Wouldn’t you like to have the tools and mindset to help them learn to feel confident and relaxed while the people around them are panicking? I mean, think how valuable you’d be to them! Not only that, you’d have so many of the things that most people want from their work: relevance, impact, tangible results. You hold in your hands a book (or a digital copy thereof) that will help you move in that direction. Been there; done that; feels great.
Why do we need another book on this topic? I mean, the basic ideas of TDD and programmer testing haven’t changed since we invented the first computer: start by articulating the output you want, then change the program until it produces that output. We can do that on a Turing machine. What’s different? Everything. Tools. People’s expectations of software. The kinds of software we build. The platforms we build on. The pieces available to us to put together. How we run software. The attitudes of the people we build it with. The attitudes of the people we build it for. The whole context has changed and those changes are accelerating. If you read a 20-year-old book on TDD (some of us have written some classics!), you’ll find yourself nodding furiously in some places and laughing in others at how quaint software development was way back in the 1990s. “That’s so cute: you burned CDs and mailed them to people?” Some important tradeoffs have changed: automation and distribution has never been easier, development environments have become more complicated, and integrating existing systems seems to have mostly replaced building things yourself. This changes our strategies. Even the superficial changes between now and then are enough to create significant emotional distance between today’s reader and yesteryear’s writer, and this distance is enough to turn many of today’s readers off. Every so often, another seasoned practitioner needs to write a book that describes how you ought to do things today with today’s tools and today’s people dealing with today’s problems. Chris has written that book. Moreover, he has added more hard-won experience and another perspective and style to the conversation. We need more thoughtful, caring, determined contributors like Chris.
Yes, caring. Chris wants you to succeed, so he shares all his best tricks. He helps you deal with the people problems in addition to the technology problems. He doesn’t hold back. He takes a practical view, but he doesn’t gloss over the hard parts. He doesn’t recommend anything that he doesn’t do himself. He doesn’t want to waste a moment of your time. All this comes through in his writing. You can’t miss it. Don’t be fooled by that gruff exterior. That’s performance art, personal branding. Chris cares deeply bout helping you do better work. If he points his finger at you and growls, it’s because he knows you can do better. So do I.
What are you waiting for?
– J. B. Rainsberger. Summerside, Prince Edward Island, Canada. May 2017.