Ed Gibbs is apparently about to embark on a little mission constituting presentations, seminars, and pair programming with the goal of test-infecting a group of developers.
The common responses he lists do indeed have a familiar sting to them. Here's the deal: you can't convince someone who's thinking about TDD like that by talking. There are some people who, based on the extensive experience, recognize the enormous value a technique like test-driven development has to offer. And then there are lots of people who will only believe the marketing once they've tried it themselves.
In my job as a TDD coach (among other things), the hardest but also biggest win is to convince a strong, self-confident individual to give it a shot. A single, honest trial of a week or two has made many a skeptic become a test-driven developer and as such a more productive developer for the organization. For some, pairing for 30 minutes with someone who knows the ropes is enough to really "feel" the support and guidance tests give you when developing test-first.
A couple of years ago, I was convinced that "selling" agile methods to management was the most difficult part. I was also convinced that selling low-level, agile techniques such as pair programming and test-driven development to management was much more difficult than selling the idea to developers. Boy was I wrong about all that.
In the end, it all comes down to motivation.
In an organization trying to adopt agile methods, what are the drivers regarding the change from management's point of view? Profit. Higher quality, faster lead times, less operational costs. All that equals higher profit.
Now, think of the developer in that same organization. What are the drivers she's affected by with regards to the organization pushing agile methods, writing tests first, or--god forbid--pairing with another programmer? It's not profit, that's for sure.
Safety. This is all based on just my personal observations but I have come to believe most developers' biggest issue with, say, TDD is not whether it's more productive or not. I believe that most of the time the biggest issue is that of insecurity. Insecurity of people around you suddenly realizing you've developed software in a less than optimal manner for all your career (which isn't the case!). Insecurity of not knowing whether you will be able to learn a new trick. Insecurity of not knowing whether you'll suddenly become the other end of a pecking order.
I've said this before (and many others before me). Change is hard. Sometimes it's so hard we don't do it, even though we know it would probably be for the better. These are the kinds of challenges I enjoy struggling with, even though I might feel outmanned and overpowered at times.
(I found Ed's blog entry via Bieber Labs)
I think you start with customers; customers who are fed up with long timelines, high bills, and results that don't match their needs; customers who are ready to stick their necks out and try something different; customers who have a high-risk, high-visibility, small-scale project to be done, and the budget to do it. That's how we started an Agile practice at our company, in the middle of a very traditional, old-school IT organization. here's the story. We started with six people and now we have 70. We started with a skunkworks project for the manager of one business unit, and now we've been incorporated into the mainstream IT organization as an "alternative" approach to software projects, with more projects in the pipeline than we can handle. Baby steps.
Ben, I used to see that too. Nowadays, I'm not so sure if that really was the reason I heard all those "takes too long" and "too difficult" arguments. Digging deeper, why is it that people say so before giving it a try and seeing for themselves? Yes, for some it's because they honestly don't believe it could work. Yet, I'm pretty darn sure that there's a non-trivial portion of people who--even though they might believe that's what they believe--are really just subconsciously protecting themselves by dismissing a new idea rather than exploring it further.
The trick is, of course, in finding out which is the underlying issue.