Up-front admission: I am not “a software developer.” I dabble in software development. I work with software developers; I test and support their code and, though I write some code (and some of that has even shipped to customers as part of various products) I am not “officially” a developer. I don’t even play one on TV. What I am is someone who enjoys working with, learning from, and exploring the software development zeitgeist. For the past year or so, perhaps longer, that has included Test Driven Development (TDD).
The basic idea behind TDD is that a developer should not only write code to test their code (in itself a recommended practice, though not widely enough embraced), but that those tests should be written first. In a way, this falls into the “measure twice, cut once” idea of making sure you’re doing the right thing. If you’re a software developer and haven’t heard of TDD, stop right now and go start reading.
Friday I was working on a project, a small application I’ve been writing to compare data on multiple systems. I had started off earlier in the week rather idealistically, designing a few classes and writing the tests for them first. That all went well. Then I got to the “real work” of the app, opening connections to the databases, getting data from them, combining & comparing data. I ran into some difficulties, and I must have spent about two hours trying to figure it out including about an hour of one of our senior developers’ time. Once we found the problem, it was one of those simple “oh, I should have seen that!” moments. Problem solved, only three “man-hours” spent.
Then this morning, over my Cheerios and coffee, I’m reading a little of Robert Martin‘s Clean Code, specifically Chapter 7 on Error Handling. There’s a section on writing one’s try-catch-finally statements first, and while I’m thinking about that I realize that – though I did that Friday – what I didn’t do was to write any tests for all that database code. I was catching exceptions and all that, but I’d never actually tested what the catch was reporting. Doh! If I’d taken half an hour to do things “right” on Friday morning, the afternoon would have been a few hours shorter.
So why didn’t I do it “right” the first time? Because it’s not a habit. It’s not the way I’m used to working. Even though I know I should, when things get rolling it’s just not the first thing that my brain and hands jump to. And again, I’m not a full-time, “real” developer with years and years of ingrained habits.
Peter Provost writes that Kata are the Only Way to Learn TDD. I don’t know about only, but without forcing yourself into some repetition, the habits won’t be formed and you’ll too easily find yourself three hours into fixing a problem that shouldn’t have existed in the first place.