DEV Community

Cover image for When is a quick and dirty hack justified?

When is a quick and dirty hack justified?

Ben Halpern on July 08, 2020

Collapse
 
vunderkind profile image
mogwai
  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.

Collapse
 
ben profile image
Ben Halpern

Very well said.

Collapse
 
willparr profile image
willparr • 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 😉

Collapse
 
tinussmit profile image
Tinus Smit

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 😁

Collapse
 
viguza profile image
Victor Guzman

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!

Collapse
 
jsn1nj4 profile image
Elliot Derhay • 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... 😔

Collapse
 
srleyva profile image
Stephen Leyva (He/Him)

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.

Collapse
 
lovedebug profile image
lovedebug

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.

Collapse
 
alainvanhout profile image
Alain Van Hout

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
Collapse
 
xowap profile image
Rémy 🤖

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 :)

Collapse
 
andonary profile image
Ando NARY

Agreed !

As long as the quick and dirty hacked will be fix when you're not in a emergency anymore (ASAP is prefered), we can eventually forget it

Collapse
 
merri profile image
Vesa Piittinen

When you're aligning items in CSS.

Collapse
 
krtobias profile image
Tobias Krause

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

Collapse
 
vonziu profile image
Konrad Stącel

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,

Collapse
 
iamschulz profile image
Daniel Schulz

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.

Collapse
 
patopitaluga profile image
Patricio Pitaluga

Five minutes before deploy

Collapse
 
icaromuniz profile image
Icaro Muniz • Edited

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

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

Collapse
 
sm0ke profile image
Sm0ke • Edited

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

Collapse
 
adam_cyclones profile image
Adam Crockett 🌀 • Edited

It is justified if accountable.

"Mom I broke the TV but I stuck-it back together with tape", is better than. "Why is the TV broken!" 🤷‍♂️

Collapse
 
mxldevs profile image
MxL Devs

When it's time-sensitive. That jug of water is leaking? Slap on a band-aid and then figure out a proper solution.

Collapse
 
gwutama profile image
Galuh Utama • Edited

For me there’s only one. And that’s when the third party system/app/api/library/whatever does not fit your purposes but you are forced to use it anyway.

Collapse
 
guitarino profile image
Kirill Shestakov

When it's not and cannot become a foundation.

Collapse
 
elmuerte profile image
Michiel Hendriks
  1. Never
  2. Never
  3. When you have a proper solution ready
Collapse
 
aryamaan08 profile image
Aryamaan08

In that case, the people who originally made QDOS must be some kind of geniuses.