Archive of published articles on March, 2012

Back home

Why I hate Test Driven Development


I have no problem saying that I write good code. I place a focus on TDD and thorough unit and integration testing. I document everything I write (not just function documentation- I document classes, modules, and systems). The fact is, since I’ve been doing these two things somewhat religiously, the amount of time I have spent debugging code has gone down dramatically. There are just not many bugs to find in most of the code I write, they are easy to narrow down when I find them, and they rarely regress.

This is a good thing, isn’t it? So why do I hate TDD?

Because debugging is fun. There, I said it. I love debugging. I think lots of clever people like debugging. I love someone having a problem, coming to me, looking at it together, getting up to walk around, look at the ceiling, talk to myself, stand in front of a whiteboard, draw some lines that spark some idea, try it, manually test a fix out, slouch down in my chair staring at my computer lost in thought, and repeating this until I actually find and fix the problem. Not just think I fixed it, but really sure that I fixed it because suddenly it all makes sense. At which point I spring a terrific boner for my obviously superior brain power that was able to find this problem that plagued mere mortals.

So the sad fact is, since I’ve been doing TDD, I haven’t been able to go on this ego-trip a single time in our TDD-written codebase. Sure, sometimes we get a bug in the UI, but those usually manifest easily. Oh, and I’ve definitely used some frameworks and API’s improperly and caused bugs because of that. But those are the annoying types of debugging we all have to do, not the  magical mystery tour described above.

I didn’t realize how much I missed debugging until it was gone. Fortunately, there’s still lots of legacy code and API’s to get my fix from.


Judging architecture by ‘if’ statements required for a new feature


I was doing a code review today on a feature added to some poorly-architected system, and compared it to the code required for features added to well-architected systems. I suspect the quality of a system can be determined by how many ‘if’ statements are required to add a new feature. Poorly architected systems have the peculiar attribute that adding features is often a matter of littering or adjusting ‘if’ statements through the system, often with a class or function or two added somewhere. Well architected systems can normally see features added by scaling “horizontally”- creating new classes or functions, passing those ‘into’ the system, without any actual adjustments to the system code itself. Furthermore I usually find well architected systems easier to refactor, so places that would require an ‘if’ statement to be added or changed, can be refactored to avoid or remove the ‘if’ statement, often making the core of the system itself simpler overall.