The First Virtue

Sigh.  Oops, I did it again.  And I don’t mean quoting an ageing pop star.  I broke the build.  I checked in something I thought was right – it was a simple search and replace, and I chose the wrong constant.  I was replacing a hard-coded value with an enum – doing thankless cleanup which will one day allow us to re-order this collection (ok, it’s way too risky for us to actually do that, but at the very least, we’re gaining a descriptive index, telling us what we’re modifying).  The good news?  We have unit tests that caught it – our code coverage is still producing numbers that we justify with a “legacy code base” but it is good enough to catch errors like this.  The bad news?  I’m on holiday having a relaxing week to myself, several hours drive away from the nearest computer with said code checked out and one of my colleagues has emailed me to inform me of my dump and run.  I didn’t want to leave any half-baked tasks lying about when I was on leave, so I was doing some “safe” janitorial work.  When it came time to check in, I exhibited the first of Larry Wall’s three virtues – Laziness.

We’ve all done it.  We will all continue to do it.  Why are we kidding ourselves that there is some magical pixie dust in the form of the latest testing trend that will save us from ourselves?  Test Driven Development is a wonderful idea – I heartily encourage it.  I even try to do it myself sometimes, because it really works!  So why don’t I do it all the time?  Why don’t I even Unit Test all the time?  That, Detective, is the right question.

I suppose the right answer is one I don’t think I would have expected to hear myself say a couple of years ago.  It’s not because of the mental effort required to set up the test.  That’s often fairly straight forward – they have a nice habit of just falling out nicely at the last moment (provided someone else has done some unit testing in a similar area of code prior) – and besides, much of why I’m in this line of work is because mental effort is required.  So is it really that laziness creature?  Nope.  I don’t think so.  Not even using Larry’s slightly different slant on it.

I think it’s because writing unit tests make writing code too easy.  I still have to exert mental effort, but it’s at the wrong end of the process.  It’s not during the wet, messy, creative portion where you’re up to your elbows in if-statements, it’s during the dry, scaffolding stage, where nothing is actually created, much of the code is straight forward and has very little about it that can be described as elegant.  It’s functional, but boring.  So I think I avoid unit testing, because I crave the battle of my mind against the machine.  And I want to do it where I’ll need to wash the mud-splatters off afterwards.

Unit Testing, in particular Test Driven Development forces one to understand the code they are about to write and make it testable, with nice interfaces.  It helps you to be clear about what the code you’re writing, by breaking the logic into small, testable chunks.

Which is all very well and good, and it forces two designs (at least) to be written.  Your first “happy path” design, which is almost always wrong or missing something vital, and then the one that actually works.  But in my humble opinion, it takes much of the fun out of coding. Yes, I have commented that it reduced my workload (and probably therefore stress) in retrospectives, you know, doing things The Right Way, but it removes the organic, creative part for me.  Most [good] engineers are very creative people.  I know at my workplace there are many musicians, cooks, bakers, brewers, photographers and even some regular old painters and that’s not, I suspect, a co-incidence.  It turns out that I’m not the only one who enjoys the wet, creative process.

So testing is A Good Thing.  I totally agree that we should be doing plenty of it.  I do get a buzz out of writing correct programs before they’re inflicted on the rest of the team.  I like the safety net they provide.  I like the modular designs that come as a result.  But I don’t like it when they become a chore.  So how do we make writing testware just as mud-splatteringly buzz-worthy as battling with raw creation?  Again that, Detective, is the right question.