I often hear co-workers saying to each other, "That's a horrible, horrible hack."

What I can take away from that is that it's not good. When I asked them if it works they say "yes, but it's not good". Does that mean it's not a good solution? How is a solution bad if it works? Is it due to good practice? Or not maintainable? Is it using a side effect of code as a part of your solution?

It's interesting to me when something is classified as a hack. How can you identify it?

  • 5
    Something may work but be slow, fragile, ugly to work with and painful to maintain. This is a hack.
    – Trezoid
    May 4, 2011 at 1:36
  • 1
    Ghetto-rigged code == hack May 4, 2011 at 4:37
  • I'm not saying it's a hack, but you want to rethink dynamically monkey-patching + to divide based on heuristics.
    – dietbuddha
    May 4, 2011 at 4:42
  • For all those who states that hacks are dirty band-aids, please look at what came to mean for those who called themselves hackers at outpost9.com/reference/jargon/jargon_23.html#TAG824 - 2. /n./ An incredibly good, and perhaps very time-consuming, piece of work that produces exactly what is needed.
    – user1249
    May 4, 2011 at 17:27
  • 1
    A feature that is not implemented as per popular standards or by your superior's standard.
    – Aditya P
    May 4, 2011 at 20:15

17 Answers 17


It's applying a temporary band aid to a large gaping wound. It's fixed for now, but it is going to cause even more problems later.

An example I've recently seen: You want a person named "Jim", to always appear first in an alphabetical list. To quickly solve it, you rename him to " Jim". This is a hack that will surely come back to bite you later.

  • 34
    Or you could call him "AAA Jim".
    – compman
    May 3, 2011 at 17:43
  • 4
    Another example would be extending an if...else...else...else due to time constraints, instead of a more extensible solution.
    – Phil Lello
    May 3, 2011 at 19:15
  • 29
    And the real solution for making Jim to appear first in alphabetical list is, of course, to reorder the alphabet.
    – artem
    May 4, 2011 at 2:53
  • 1
    @artem true, and it looked like this jzbcdefghiklmnopqrstuvwxya (you dont want to have to reorder the alphabet, to take down a and bring up z) May 4, 2011 at 12:54
  • 1
    To phrase it in project management terms: a hack is a solution that could create a future a debt of time/man hours, and/or goes against best-practices or standard conventions.
    – Incognito
    May 4, 2011 at 13:26

Every engineering decision is a tradeoff between immediate cost and delay and the consequential costs and technical debt.

A hack is a situation where the former is preferred while accepting the latter as a consequence.

Inexperienced developers (partially because of the way the engineering education system works) focus on the former and do not have sufficient experience to truly understand or estimate the latter.

Experienced developers do, but for various reasons (many legitimate) choose the former.

The term hack almost always implies an intention to solve a problem temporarily and "do it right afterwards", but experienced developers know that the most permanent things in code are temporary hacks.

  • 13
    +1 for "but experienced developers know that the most permanent things in code are temporary hacks"! Which also means that laziness should never prevent you from doing it right. May 3, 2011 at 17:15

How is a solution bad if it works?

Consider this

2 + 2 <-- Correct.  Elegant.  Simple.

(2/1 + 2/1) * 1/1 <-- Also Correct.  Lots of useless weird code.  

The second example, however, might be hack that gets used because of ignorance of a better practice or an assumption that made /1 seemed simpler at the time or a bug in a library that made the /1 work correctly.

Is it due to good practice?

No. Hacks are "expedient" code. There are three four causes.

  • Ignorance of proper design principles. (i.e. SOLID principles)

  • Arrogance (i.e. mistaken assumptions) about an API or language construct.

  • Actual bugs that aren't solved but are worked around.

  • Management override to good design and correction assumptions. "Budget" is a common justification, but this is essentially one of the above three (ignorance, arrogance or error) with a non-technical root cause.

Or not maintainable?

That's the point. The hack is based on ignorance, bugs or assumptions.

Is it using a side effect of code as a part of your solution?

That's can be an example of ignorance or a false assumption.

  • Great answer, but doesn't take into account that hacks are sometimes written with quality being pinched due to the Quality vs Time vs Cost triangle.
    – StuperUser
    May 3, 2011 at 17:28
  • 1
    I use to play that game with clients. I'd ask them to pick the two most important aspects of a project from Quality, Time, Cost. Almost always Time and Cost were picked, and then they'd haggle on quality. Specifically, citing the fact I was a consultant and should be able to deliver all three under time, cost and with outstanding quality. This scenario is like Hen's Teeth! May 3, 2011 at 21:03
  • 1
    @Optimize: Hens teeth are rare. Is this situation rare?
    – Matt Ellen
    May 3, 2011 at 21:40
  • @Matt Ellen: It may be a different use of the phrase "Hen's Teeth". It may mean "contradictory" instead of "rare".
    – S.Lott
    May 3, 2011 at 21:47
  • I find that it's almost always the "management override" decision. May 4, 2011 at 3:26

Hack in programming context would be equivalent of fixing something with duck-tape or bubble gum.

Hack very often involves using some undocumented and unsupported features, which might change in future breaking your code. They might also involve hard-coded values.

Hack typically might also be temporary work around in code using some library/service, instead of solving underlying problem. If later is beyond your control, hack might be the only way of dealing with it.

  • 21
    Using duck-tape for ducts would be a quack ;)
    – JeffO
    May 3, 2011 at 15:58
  • quack quack quack May 4, 2011 at 0:55

The term is occasionally used with the opposite connotation, as in a "brilliant hack." Just because it is a lot more common to screw up than to do something brilliant it is a lot more common to hear about horrible hacks than brilliant hacks, but I have heard the term used both ways.

"Hack" used in the positive sense basically means an elegant solution that solves the problem in an unexpected and particularly clever way. The negative and positive meanings are actually kind of close because a brilliant hack often involves taking advantage of an unintended aspect of the technology.

  • 1
    Its a brilliant hack because it will be hard to see what you did on the surface but that, upon further detailed inspection, it is obvious that this is ridiculously clever left field code. May I direct you to the quake square root magic: codemaestro.com/reviews/9 May 4, 2011 at 2:31

A solution that works right now, but will probably cause problems in the long run.

Example: you need to generate an HTML document, filling in some values dynamically. The proper way to do this is to use one of the tools that are actually designed for this purpose, like Freemarker, or XSLT, or JSP. But you can't use any of those, or you just can't be bothered to do it properly, so you write something like this:

public String getGreetingPage(String name) {
    return "<html><body>Hello, "+name+"!</body></html>";

A hack is an ingenious solution to a problem, often depending on out-of-the-box thinking and taking advantage of unexpected facts about the environment. There's a saying out there about the archetypical hack that viewers agree it's ingenious, but can't figure out whether it's wonderful or horrible. This is the sort of thing you don't want in your maintenance fixes.

A hack that fixes a problem will very likely depend on the details of the environment, or undocumented features of a tool, or something like that. It's likely to be a brittle solution, working now but likely breaking when something changes. It may be difficult to understand how it works, and any maintenance programmer will hate hard-to-understand code. It may have side effects that don't hurt anything for the time being but will cause problems in perfectly good pieces of code some distance away in the future, and that can be a nightmare to deal with.


The word hack is misused. If you want to really get a bit of history, you can Wikipedia it. A hack is a word to describe the process of tweaking things to do something they were not meant to do. In the context of electrical engineering, this is good. There is a better description on Wikipedia on this.

Now, In the context of computer science. A hack is generally bad. Yes , it does work but usually it means that the programmer wrote some ambiguous piece of code that is not complying with the design of the software and that will confuse every programmer who has to read that code. Of course programmers time is expensive, so as a manager one wants to have the most easily maintainable software. The same is valid for programmers. Also, hacks tend to break something else, in the software.

It is a judgement call whether to accept the hack or not. At least you want the senior software engineer to approve the hack, since he has more experience and is able to make a more educated decision. Definitely you don't want the junior guys to make decisions about accepting hacks. They can come up with one and discuss with the senior guys whether the benefits are worth the pain of maintaining the hack.


This is a hack, as found on thereifixedit.com.


Actually about everything on that site is a hack.

Hacks are ingenious and audacious uses of some things out of their context.
The beauty of a hack consists in the fact, that you have a given problem and tools that were never intended to solve it, but you solve the problem with just those tools (instead of getting the right ones). They are clever, fast and fun. The downside is, that the results are often fragile and dangerous to use for outsiders.
I mean, if you like solving your problems as in the picture, there's no problem. The problem occurs, when you solve other people's problems like that. In this case, they would probably get electrocuted or burned or something.

In software development, you want that your code can be handled by others (which includes your future you) without the equivalent of a fatal injury. As Dijkstra put it:

The competent programmer is fully aware of the limited size of his own skull. He therefore approaches his task with full humility, and avoids clever tricks like the plague.

And hacks are among the most clever tricks.

Hacks are ticking time bombs somewhere in your code, because the common ones are inherently based an too many assumptions ("just doing it" is preferred to proper decoupling). As soon as those assumptions no longer hold, your whole system can break down without you having any idea what happened.


The term is not very precise but it is probably referring to a quick-and-dirty solution to a problem that is difficult to solve properly. The solution in question probably works, but is probably not a very good implementation, maybe have subtle bugs, maybe some small known bugs, and should be redone later, if time permits. I think what you are hearing called a "hack" is also sometimes called a "kludge".

I often see hacks happen when there are very tight time constraints to finish a task, and a hack solution is implemented because it works "just enough" to pass QA, with the hopes that it can be fixed later on. Unfortunately, that later fix/clean-up doesn't always happen :(

  • I'm not sure what you mean by "not very precise" - I'd say most programmers would know exactly what is meant by saying some code written is a hack. But the rest of the answer is spot on, it works, but for some reason (architecture, performances etc) it is not an optimal solution.
    – ozz
    May 3, 2011 at 15:11
  • @james: In my experience, two programmers can look at some code and one will call it a hack, the other will not. There's no realy way to quantify a piece of code as a hack. Everyone has their own idea of what a hack is, and often they are similar but not always the same. Written as someone who has had his code called "hackish" by others, and disagreed. And I've called other people's code "hackish" and they disagreed. True, those are probably boundary cases, but the boundaries can be fuzzy at times... May 3, 2011 at 15:25
  • 1
    @FWFD - that's just disagreeing over whether something IS a hack. If someone "says" some code is a hack you'd know what they meant.
    – ozz
    May 3, 2011 at 16:51

I spend a lot of time as a front-end developer , so my definition of a hack is :

A solution which is based on in-depth knowledge of environments flaws and undocumented behavior.

The environment can be your framework, web-browser, database, ATM (cash dispenser), court-case. Any "system of rules", where you know a loop-hole and exploit it to solve a problem.


A hack is usually some code that apparently does provide the desired output, but in a sub-optimal manner.

It is usually using some undocumented or obscure language/library feature in some way that was unintended by the originator and thus obfuscated what the intention is.

Occasionally it is done to work around some language or library bug but in most cases the main cause is usually ignorance;

To a hammer everything looks like a nail.

Things that are done in round about inefficient manner, usually in both space and time, but eventually produce the desired output, but at a cost, and possible un-knowable edge cases with no testability and no maintainability. Usually stemming from a lack of fundamental understanding of logic or language idioms. Also see "the hard way".

Usually the code is something that someone with the appropriate experience would not even consider doing, or would have to think long and hard to make it as complicated and inefficient as the round about hack that they have uncovered.


The Vista Fix

Email Validation Validity

Units of Software

Non deterministic Hash

  • +1 For suboptimal. And because hacks aren't necessary "temporary" as the top-most voted.
    – rlb.usa
    May 3, 2011 at 17:58

A bald tyre works but no one would call it an ideal solution to a puncture. It may create worse problems down the line.

Typically I'd consider a hack as a quick and dirty solution to an immediate problem. It may typically not conform to normal programming practice in a programming shop (eg, use a lot of hardcoding). It may well be a small fix.

A key reason it's bad is that a) it may cause unpredictable results b) it may not match the original design of the code in question which will cause maintenance problems. In my experience, hacks are typically very poorly documented also.


A short definition which I've heard and come to respect:

"A solution to a symptom which does not fully solve the problem in all cases"

Ugly code may or may not be a hack. The 2+2 example in another answer is not a hack, it's an ugly code solution and bad from a code-understanding standpoint, but it produces the correct solution in all cases. Think of a factored equation in mathematics- the behavior/relationship is identical and correct in both versions, but the form is different. Hmm, factor an equation, refactor an equation, refactor code... no, no similarity I'm sure :)

The example in one of the other answers about changing the first name to "Jim" is a hack: it solves the symptom (first name in the list is Jim), but doesn't fully solve the problem (the list isn't sorted or prioritized in any way that works for all entries).


A hack is doing something that returns the expected result, but does so in a strange way (usually incurring a performance hit).


Task: To Cast an Integer Variable to a Double

Solution: Use the Cast Operator. I.e.: dblVar = CType(intVar, Double)

Hack: Divide by a Double. I.e.: dblVar = intvar/1.0

  • +1 for a stellar example. In old AS400 code I'll see European dates multiplied by some wacky decimal, that outputs the American date. The problems begin when certain coders start leaking that into our .Net code...bleh! May 4, 2011 at 13:51

Imagine if your leg got infected and had to be removed so that you would survive. Would you rather have the doctor quickly hack it off with an axe, or surgically remove it after examining the problem and picking the appropriate tools, procedure, etc? The same applies to software.

  • I'd have him hack it off before the attacker gets a chance to hack into my brain. May 4, 2011 at 0:57
  • What if you only had a few minutes?
    – StuperUser
    May 4, 2011 at 11:11

A hack signals it's birth when the coder responsible declares "I'll come back and fix that later".

On a serious note - a hack in the context of the OP is something that achieves the desired result, but uses a temporary or unreliable method to do so.

The other common definition is a technique that exploits edge case behaviours to circumvent limitations/safeguards in the platform.

Hack in the second context has a certain cachet among "maverick" (read: dangerous) hero-coders...

Not the answer you're looking for? Browse other questions tagged or ask your own question.