You’re Not Gonna Fix It

It’s 2am so I’m hacking this together and cutting a few corners, which in this case it good because it puts me in the right frame of mind to talk about kludges.

I’m not going to justify the kludges, or apologise for kludges. I don’t need help figuring out how to avoid them. Generally speaking kludges don’t come about because we don’t know how to avoid them, they usually exist because a judgement call is made that a kludge is not worth avoiding. Dress it up however you like, but ultimately it comes down to a decision.

This post starts from the premise that in all liklihood there will always be kludges. I want to talk specifically about the lie that programmers tell ourselves every time we resort to a kludge.

“I’ll fix that later”.

In some cases we may even include a comment indicating that we’ve done something we’re not proud of, and perhaps even details about how to fix it.

We may go further and adopt a standard that says we should start the comment with a word like HACK, so we can find these gems later.

Let’s knock something on the head right now.

You’re Not Gonna Fix It.

If that rings a bell it has echoes of “You’re not gonna need it”.

While “You’re not gonna need it” serves as a warning against doing too much in the hopes that it will be useful later, “You’re not gonna fix it” warns us against doing too little with the promise that we’ll fix it later.

Let’s assume you’ve hit one of those moments where there’s a 5 minute fix.

Let’s assume that you’re not entirely happy with the solution. There is a better way, for the purposes of this post it doesn’t matter what the better way is.

You make the judgement call to go with the 5 minute fix. Or, perhaps the jugement call is made for you, by a manager, by the QA team drumming their fingers, by your spouse calling to say your two year old has just coughed up something and you need to get home.

You do the fix, release the code, it gets through QA, pushed into production, and it works. Great.

A month later, you’re finished the project, getting into a new project, waiting to meet stakeholders, you find yourself with a spare afternoon. A chance to crack open the code and take a swing at some of those kludges.

Now, depending on your development process this may actually be a really dumb idea. If production changes need to go through QA then you are about to create a chunk of work for the QA team. Have you checked with them that they have capacity?

What if this fails right as you get started on your new project, will you have capacity?

We’re talking about a change that brings no real value to the users, certainly no visible value. Are you going to run it by your manager?

If you were a manager would you ok a production code change just to tidy up some code that was gnawing at a developers conscience?

If you go gung ho proclaiming that it’s a trivial change the first question you’re likely to be asked is why wasn’t this trivial solution implemented in the first place. It’s funny how perception works. A change that you considered non-trivial at 6pm on a Friday evening when you didn’t really want to do it, suddenly becomes trivial when you have a spare afternoon a few months later.

In reality changes only get harder with the passage of time. You are never going to be as familiar with the code as you were when you first created the kludge. No amount of HACK comments can fix that.

Does this mean you should never pay down technical debt?

Of course not, but understand that your ability to pay down technical debt is intrinsically linked to your development process. The more “Waterfallish” your process the less likely it is that you’ll be able to fix issues later. The more people you need to take time from in order the push out a release, the more likely it is that technical debt will remain untouched.

So for some, You’re not gonna fix is is not just a harsh reality, it’s how it should be. There’s a cost associated with being able to fix kludges. So, either create a process that facilitates repaying technical debt, or get used to the fact that a kludge is for life.

Even if you have a process that facilitates tidy ups, it’s still a useful exercise to consider kludges permanent solutions. If the decision to use or a avoid a kludge is a close call, then it’s tempting to let a promise to fix it later sway the balance in favour of the kludge.

Next time you are in that situation, throw in a promise that this kludge is for life and see which way the scales tip. If they still fall in favour of the kludge then go with it.

If the realisation that “You’re not gonna fix it” tips the scales the other way then you’ll have your answer.