The Second Virtue

As I discussed in my previous post Unit Testing is a Good Thing.  But once you’ve got enough testware, it starts to become a burden.  At that point, most companies worth their salt will invest in some high-spec hardware on which to run the continuous integration system.  This is seen as an opportunity to increase productivity by knowing earlier when some code is wrong.  This is sound logic.  But this doesn’t solve the problem for the developers trying to run the tests before they check in said breakage.  Larry Wall’s second virtue, Impatience, starts to come into play quite significantly here.

I have personally spent a lot of time and extended effort into making a large, complicated C code base build and test as accurately and quickly as possible.  And even then, with the build spread across eight 12-core blade servers, each with 32 Gb of RAM, we manage to build and test in around 20 minutes.  Now, even though the developers have high-spec’d four core boxes, they still can’t even come close to the raw power of eight server-class machines, even if they can borrow some of their CPU time with distcc.  We’ve therefore created a partial build which attempts to build just enough to catch around 90% of the errors with only a small portion of the required effort and even that can take upwards of half an hour.

Where, then, does the balance sit?  How much do we require gets built for every change before every developer is slowed down enough such that it actually becomes faster to just check in and hope (for a given value of hope).  And anyway, how many people are updating so often, without taking note of the readily available state of the build, such that they’re feeling the pain of the build being broken.

Read more of this post


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.

Read more of this post

Introducing The Coding Monkey Me.

Ahhh, the inaugural blog post.  Where I have almost no content, just a shameless self-promoting ramble.  Well, here goes…

I’m a 27 year old professional software developer.  I graduated in Computer Science from the University of Canterbury, New Zealand in 2007 and after a short stint looking for “real” work, I began working as a code monkey in mid 2008.

That’s right, I’m only just  4 – barely old enough to be allowed toys that come with a “choking hazard” warning and I have the audacity to be blogging about my exploits as though I know what I’m talking about.  Let me clear that one up for you here and now.  I’m not an expert.  I’m not a prodigy who’s been coding since I was 2 years old.   Much of what I have to say will be total crap, purely my own opinion and should not be associated with my employer in any way shape or form.

Read more of this post