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.
Hi, Will,
I really enjoyed talking to you; we definitely had some great conversations.
It is important to remember that continuous improvement is about looking ahead, not backward. I think you are on the right track when you say that you are going to look for concrete steps to improve your team. Some people look at their past and feel sad about not having tests. However, the past is gone, all we can do is try to do better tomorrow.
One of the wonderful benefits of testing, in general, and TDD, in specific, is that you can generally guarantee that bugs won’t appear twice. The same goes for improving your process: try to enact steps that keep you from making the same mistakes in the past. Take time periodically to reflect on mistakes that may have been made in your process, then take concrete action to keep them from happening again.
Keep in touch, and I’ll look forward to seeing how you move ahead.
@Corey Haines
Thanks, I really enjoyed talking with you, too. You gave me a lot of things to think about.
Regarding looking for concrete steps, I totally agree. I actually had a chance to speak with my manager this morning about some of these things. Just as I thought, a lot of my fear was in my head; My manager is totally receptive to my ideas, and he thinks the team will be, too! Sweet!
Also, my manager asked if anyone I met was available for consulting (in regards to helping us identify the issues and concrete steps to address them). So, there may be an opportunity to bring you in for a couple of days to help coach us. Email me (see the about tab, above, for my contact info) if you’re interested.