Sometimes you write code that is really important, sometimes you write code that is not and other times you write code that is somewhere in between. Should you apply the same quality standards to all of that code?

It really comes down to a question of value – code that you write once, run and then throw away obviously doesn’t need to be pretty and certainly doesn’t need any documentation. What about code that you keep around, make the odd change to and run regularly but is of low importance? What if it just doesn’t matter if the code breaks? Where is the value in making the code robust and easy to maintain?

Over the past week or so I’ve been working on code that fits into that grey area between code that obviously needs to be high quality and code that just doesn’t matter. I’ve been writing an AppleScript to pull various bits of data about our development progress and code quality and generate a bunch of graphs with that data. Now if I were really good at AppleScript, I could probably whip up high quality scripts in a short time frame, but I’m not so just getting it working can be time consuming. I just can’t see the value proposition in spending a lot of time cleaning up this script when it doesn’t matter if it fails and the number of changes I’m likely to need to make to it are very small. Besides which, the time required to completely reimplement the script is pretty low – most of the time I’ve invested in it was learning how to AppleScript Excel and how to use the various command line programs it uses to parse the data. Now that I have that knowledge it’s pretty simple to do.

I’m also inclined to not worry about it too much, because if I were concerned with the script I wouldn’t have written it in AppleScript – it would depend on OS X, Excel, GUI Scripting and various other things – I’d probably write it in Java as a full blown application. Yes it would take much longer but it would be something that anyone on the team could run and would be expected to have the skills to maintain. I doubt anyone else on our team has ever seen an AppleScript, let alone had to write one. Does it matter? Not really. The extra time to write it in a language that the rest of the team knew would have made the project cost more than it was worth. Let’s face it, having a few basic graphs about your project’s health isn’t that valuable when you already have the reports available.

The catch however, is that if this code were to ever become important I need to make sure that I go back and make its quality match its importance. That is, I’d need to take the time and refactor the code to make it more robust and easier to maintain – I may even need to rewrite it from scratch so it doesn’t have so many dependencies. For now though, I’m happy that it is automating a process that I could do by hand and bringing value to the team.

Judging the value of code can be hard at times – it’s easy to think that some part of your product is rarely used or unlikely to break, but there’s value in avoiding software entropy – it’s actually costly to introduce bad code to your code base even if it doesn’t ever break because it encourages you to get sloppy in other places in your code. A while back I argued that code should be beautiful and I stand by that, including the follow up: Beauty Is Only Skin Deep. In those entries I was talking about any code that you ship to clients or anything that impacts on your actual product. Don’t risk failing your users because you didn’t care enough about your code. At the same time, don’t let the cost of writing beautiful code, or even good code, put you off automating tasks that you do repetitively, or on little tools to make your development life easier – just don’t let that code get anywhere near your actual product.

What’s the lesson here? Ask “Where is the value in what is being done?” constantly, including when you decide on the required quality levels.