When is a quick and dirty hack justified?

#discuss #codequality

Top comments (24)

mogwai • Jul 8 '20

When you know what you're doing is a quick (and dirty hack). That self-awareness is a core ingredient for taking hack-aware measures, such as documenting your code, planning for technical debt, and knowing exactly when things will come to a head.
A quick and dirty hack is never justified where security risks are concerned, in my opinion. With that said, I've launched a product in the past that had a glaring security hole. It wasn't oversight on my part - I just didn't have the time to fix it before launch. Mercifully, post-launch I got volunteer devs who joined me in working on it (it was an open source project).
A quick and dirty hack may be a go-to method when the thing you're embarking on has so much schlep that doing it right the first time almost certainly means you won't do it at all. In such a situation, it may be easier to fix a hacky solution than to start from no solution at all. I guess that's the point of all MVP philosophies.

Ben Halpern • Jul 8 '20

Very well said.

willparr • Jul 8 '20 • Edited

Taking security out of scope, the only time a quick hack is justified is when it is quickly followed up later with the "correct/clean" solution and documented at the initial implementation. Otherwise it sits in production and tech debt is continually built on top of it.

So in my opinion it's justified if it's going to be removed 😉

Tinus Smit • Jul 8 '20

Came here to say exactly this. If it's an issue in production and time is of the essence, then yes. Bring the crisis down to a problem, and deal with the problem, I say 😁

Victor Guzman • Jul 8 '20

Just today I had to come with a dirty hack! We are using an API that for some reason has case sensitive http request headers, and ruby applies some case changes to headers when sending requests.

And since we don’t have control over that API, we had to create a string subclass and override the case methods to do nothing and be able to pass request headers in the expected case.

It was a nightmare to find the issue btw! But it was a good lesson too!

Elliot Derhay • Jul 8 '20 • Edited

Only 1 bandaid in that cover photo? 😏

I guess I would answer your question by saying that you know the right (and much slower) way to do it and you know you're going to do it correctly soon after doing it the quick-and-dirty way.

That said, I've had quite a few of these and the only justification has been "get it done now"—or something to that effect... I'm not exactly proud of that though... 😔

Stephen Leyva (He/Him) • Jul 8 '20

Are we gonna forget the fact that a computer is essentially a hack? I mean it’s literally a rock we tricked into thinking? 😂😂

In all seriousness, technical debt is appropriate if 1) it gives you value 2) is documented so as to be fixed. The most dangerous type of technical debt is unknown and unintended technical debt.

lovedebug • Jul 8 '20

There is an emergency bug which will cause SEG P0, there are 2 methods to fix, one is dirty but fix 1 row, the other is perfect but you will touch more code lines. For an emergency fix, is is acceptable, but you should refactor in next sprint.

Alain Van Hout • Jul 8 '20

A quick and dirty hack is justified when the long-term cost of implementing the hack is less than the long-term cost of not implementing the hack (which might mean going for the clean solution or not doing anything at all). That's of course a value judgement.

Some potential ingredients for such a situation:

The business will go under if nothing is done fast (e.g. adding a hack to mitigate a very big security risk)
The hack does not add risks (that are larger than the risk it tries to mitigate)
The workings of the hack do not create extra work beyond what is feasible to do later (i.e. cleaning up side effects afterwards)
The hack does not make it harder to afterwards create a clean solution, from a technical point of view