When is a quick and dirty hack justified?

1. 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.

2. 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).

3. 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.

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 😉

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!

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... 😔

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.

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.

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

Never.

But if you're doing something that is urgent and you didn't sleep for 20 hours and that piece of code is only going to run once then I forgive you :)

When you're aligning items in CSS.

When you know this "hack" exists for several years, and they have no intention to fix it anytime soon.

When you don't have time to do something properly and it needs to be done ASAP. You have no choice but to band-aid the solution,

When its commented on code, its implications are foreseeable and there's a follow up ticket written.
Nothing wrong with being dirty here and there as long as you can refactor it later.

Five minutes before deploy

Every time that's neither
*going to production
*being used by coworkers

Apart from such cases, quick dirty hacks are fun and welcomed.

15min before fallback a database migration with 1mil users. That RAW SQL update was a saver for some jobs (including mine).