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.

Apparently a bunch.  It’s a fairly common complaint that the Mainline’s broken again.  As a result, we developers are under huge pressure to not break the build.  As soon as it’s in the red, it’s a fairly regular occurrence to get several people jumping down your throat to get it fixed.  Then comes the balancing act of reverting your change as opposed to an outright fix.  We want to do The Right Thing, so long as it doesn’t cause too much pain to (mainly ourselves but also to)  the other team members.

I’m therefore always somewhat amused when I see the look on people’s faces, when I, former gatekeeper of the build, am happy to check in to get the expensive computers to do the heavy lifting.  The faster I get the result, the better my headspace is to deal with the problem efficiently and effectively.  So I’m balancing the likelihood that I’ve massively screwed up (and I like to think that I have reasonable judgement for this probability, having had some good practice at it over the years) over the likelihood that I’m going to screw everyone else up.  Temporarily.

As I am usually so excited that I’ve just improved the codebase in some way, I am always eager to get it checked in and make it official.  I don’t know why I’m always so keen – are 20 extra minutes really going to make a difference to anyone, at all?  Especially when we won’t even publish an internal build for another week?  Almost certainly not, but I still can’t help myself sometimes.  It often takes a gentle reminder from a colleague to take a deep breath, relax and fire up the unit tests.

So I’m impatient.  I like to think that’s my passion for my work coming through.  I’m so proud (usually) of what I’ve done that I want it to make the other developers not even notice my code (perfect code is no code at all, so as second best, I’m  happy with code so un-remarkable and plainly obvious that it doesn’t even register to others), such that their day is a little less arduous should they happen to traipse through what I’ve just touched up.