Following a discussion with my boss last week, I’ve had this topic on my mind. It wasn’t until I read the excellent post “Technical Debt” by Jeff Atwood that a tag was put to the ideas inside my head.

Basically, technical debt refers to the cumulative cruft that has evolved in a system over time due to sacrifices taken and shortcuts made. When you do something purely for the sake of expediency you add to your projects technical debt. As time goes on, a cost becomes associated with that debt and due to the decisions made, you have to service the debt in some way (workarounds needed because of a 5-minute hack, that sort of thing). If you haven’t read Jeff’s post yet, I strongly recommend it. He’s much more articulate than me.

Like most programming shops, at work we have to generate revenue, and to generate revenue we have to ship things. There is never time to get everything done, and at some point during the cycle, sacrifices are made and shortcuts taken. For us, the most common place I see this happening is in the build tools and infrastructure that we put around projects. While there is an apt reverence for not taking shortcuts in the stuff we actually ship to customers, the same attention isn’t always paid to the tools we use to test and build our products.

The simple fact is that there just isn’t time for someone to take a few days or a week out of the schedule to work on building stuff to build our stuff. During my conversation I noted this and suggested that as we continue to grow as a company, at some point the ad-hoc attitude we have towards this sort of thing will start costing us.

There are a couple of reasons for this sits in my mind.

The first is that I’m incredibly anal when it comes to things like build systems. If I can’t check out code and build it in two command (*including* the command that gets the code from version control) then I’m not happy. If I can but the build fails half the time for no obvious reason, then I’m also not happy (explains why I don’t like Maven). It has to be simple and it has to be repeatable.

The thing that really frustrates me is that there are plenty of excellent tools out there, both commercial and open source, that provide a little bit of necessary structure without requiring a huge investment of time to get them set up. In response to my queries I was told that the local experience has been that mandating the use of particular tools from the top down has largely been ineffective. The changes that have been most successful are ones that have grown organically from within the teams. While I can appreciate that, the problem I see is that we now have a different build system for each project, and each on has been hacked together in a hurry. The particular idiosyncrasies and shortcomings of each has just been accepted as the way things are done in any given project.

Secondly, jumping from one project to another is difficult enough (and we do a bit of that). Having to learn a new codebase is time consuming enough, adding extra pressure on both worker and deadline. Figuring out an entirely new build system for each and every project just adds to the stack of new things you have to fight against. It is made even worse when a particular system is just plain bad, but works just often enough to remain in place. It might only be a little thing to some people, but when it comes to enjoying an experience working on a particular project, the little things matter. Happy developers are productive developers.

Personally, I think that there is an obvious benefit to having a consistent continuous integration environment across all our products, but I’ve also realised that the only way this is ever going to happen is if I get in there and build it myself. One guess as to what I’ll be trying to find time for next week. Fingers crossed it isn’t all in vain.

This entry was posted on Sunday, March 1st, 2009 at 4:00 pm and is filed under personal. You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.