A Confession: I don't do TDD, but I know I should
So, I was at acts_as_conference 2009 this past weekend. I met a lot of great people, especially the two Coreys: Cory Foy and Corey Haines, who were kind enough to spend a lot of time having very thoughtful discussions with me. The thing that struck me the most was the attitude of everyone in attendance: your code is your craft, your art, your expression of you. As such, you should exhibit pride in your work. The way we, as programmers, have to do that is working code, and the way you prove that is with tests.
This morning, I read an article from one of the Pivotal Labs guys that sums it up pretty well:
In short, if you write software, and you're not writing tests, then you're not doing your job.
I don't mean not doing your job like a waiter who doesn't take your order quickly enough; I mean not doing your job like a surgeon who operates without washing his or her hands. As in completely unacceptable performance. This is an idea that Corey Haines also echoed, though he put it more severly: if you're not writing tests, you are negligent.
I was reluctant to agree at first, but that is largely because all of the code I, and my team, write and maintain on a daily basis contains exactly ZERO tests. None. Nada. Zip. 0. I need to change this. I'm working through some ideas on how to accomplish this, and I plan to chronicle it here with a series of blog posts.
To that end, I've listened to a couple of the Alt.Net podcasts, some Hanselminutes podcasts, and I intend to read up a bit on LEAN manufacturing to really get my head around these ideas. My goal is to figure out the best way to imporve my team and our work; to turn us in to craftsmen (and women). In the mean time, if you have any sage advice on books I should read, approaches I should consider, tools we could/should use, even suggestions on the way we structure our projects, I am open and receptive.
I am an empty vessel. I invite you to fill me up.