Mike Clark gets a lot of email about all sorts of automation and continuous integration implementations around the world. This time, he got a very nice graph of the build history of a zero-defect product release. Nice!
Speaking of releases, I just noticed that Eric's latest book, Ajax in Action is shipping from Amazon. I know Eric from JavaRanch and he's a real wizard with all things JavaScript. I haven't read the book yet but I'm looking forward to it--the early reviews have been great, I've heard!
UPDATE: now also available in blue
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)