If your “hack” has been running in production for years, was it really a hack?

I can’t tell if developers are idealistic pessimists or pessimistic idealists. The most common manifestation of this paradox? Apologizing for delivering working software. The idea that one could have done a better job if only they had more time is admirable, even tragic sometimes, but should we really be so hard on ourselves? Useless Dev Blog takes a refreshingly honest look at this phenomenon in Stop lying to yourself – you will never “fix it later”

Recently I approved a pull request from a colleague, that had the following description: “That’s a hacky way of doing this, but I don’t have time today to come up with a better implementation”.
It got me thinking about when this “hack” might be fixed.
I could recall many times when I, or my colleagues, shipped code that we were not completely happy with (from a maintainability / quality / cleanliness aspect, sub-par functionality, inferior user experience etc.).
On the other hand, I could recall far far fewer times where we went back and fixed those things.

So, we realise that if we don’t fix something right away, we’re likely to never fix it. So what? why is that important?

Because it allows us to make informed decisions. Up until now, we thought that our choice was “either fix it now, or defer it to some point in the future”.
Now we can state our options more truthfully – “either fix it now, or be OK with it never being fixed”. That’s a whole new conversation. One which is much more realistic.

Emphasis mine, and emphasized because it gets right to the heart of the fundamental conflict driving all software development compromises, aka Rule 9:

Later == never, temporary == forever, shipped > not shipped

Rule 9

Well, it gets to 2/3rd of it at least. The author argues convincingly that if the code is “bad” you have a very short window to make it “good”, because once new features start relying on it you’re stuck with it forever. I agree, but there is another factor missing from the author’s calculus – is the presumptively bad code worth fixing? From the Old Testament:

As a software developer, fixing bugs is a good thing. Right? Isn’t it always a good thing?


Fixing bugs is only important when the value of having the bug fixed exceeds the cost of the fixing it.

Joel Spolsky, Hard-assed Bug Fixin’

Joel is talking about bugs, but since presumptively bad code is just a bug that hasn’t hatched yet it applies here as well. He’s also talking about value in terms of money, but that’s really just another way of saying time. Time blows the referee whistle in the 3rd part of Rule 9, shipped > not shipped. In the quantum flux of unfinished code, all possible outcomes exist simultaneously until a deadline forces them to collapse into one pull request. Sure, it could have been perfect given enough time, but if your product has to actually sell and serve customers there is a point on every new feature or fix where good enough will have to do. I’ll take someone’s working hack over their hypothetically better solution that doesn’t exist every time.

Rule 9 – Even in space, temporary==forever

An entertaining conversation with a colleague gave me reason to revisit the source code for the Apollo 11 flight computer…the one that landed the first humans on the moon. The comments are all too relatable.

Image stolen from MIT/NASA

An ABC News article runs through the best Easter eggs and comments. The full source code is available on GitHub, natch. If there is a lesson to be learned for modern software developers, maybe it’s this: you may not think much of your “temporary” solution, but often the first thing that works is good enough. This was good enough to put 12 people on the moon and bring them home. What’s the most enduring thing your temporary fix accomplished?