You know, when one of my coworkers and I were young turks we used to scoff at the senior programmers who didn't use debuggers. "Printf debuggers," we called them. We had read *Writing Solid Code* and knew that stepping through every line of code we wrote in the debugger was how to keep our code bug free.
In a strange turn of fate, now I'm the one being scoffed at, for *using* a debugger. The scoffage comes from two sources:
- Guys with fairly academic backgrounds who like to talk about theoretical correctness. *Writing Solid Code* is anathema to them because, "Code isn't a 'solid'! It's a dumb metaphor!" To these guys, I'm a "Von Neumann" programmer - I slap buggy code down on the plate and then survival of the fittest lets the correct code get through...but there could be all kinds of theoretical bugs in there on the corner cases and whatnot that I'm completely missing and won't find out about until QA (or worse, the public) gets it. And, furthermore, with multiprocessing becoming a thing, these techniques simply won't work anymore - you can't step through MP code to make sure it's safe. You know, these guys do have a point.
Truth is, debugger-driven-development does give me leeway to be sloppy, and sometimes I'll be sloppy, knowing that the compiler is there to catch one set of errors, debugger-driven-development is there to catch another, and (sometimes) test-driven-development is there to catch others. Coding this way is a little like the poor speller using a spell-checker - theirs a hole category of mistakes that don't get cot. Really, that poor speller should spend some time with a speak'n'spell, or whatever they use to learn spelling these days.
Still, even though I (usually) try to be good and "think before coding" I'm not giving up the debugger-driven development. Because even good spellers make mistakes and it's nice to have the spell checker there to catch them. (I'm running a spell-check on this article right now. 'Scoffage' isn't a word? Get out of here! And 'turk' should technically be capitalized but it looks better this way...hmm, does Neumann have one n or two? Right the first time!)
- The TDD guys, who are the ones who coined the term debugger-driven-development, and are laughing at me because when I'm stepping through my code, checking values to make sure they're what I expect, that's really a process I should automate in test cases. And these guys have a point, too.
But there's no way that I'm going to write one unit test per LINE of production code I write, and that's the kind of coverage DDD gives me. I'll write tests for a couple of cases per function at most, and while those tests will catch a lot of the errors that DDD catches, I think it's still worth that marginal extra time (DDD takes a lot less time than writing a unit test!) to make sure each individual line of code really is doing what I intended. DDD is clear-box testing whereas TDD is black-box testing.
Don't get me wrong. I've really come to love TDD over the last year or so. Caught a bug I never would have found myself just the day before yesterday. I'm not giving up my old ways for it, is all.