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?
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.
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.
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.
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.
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.
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>";
}
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.
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.
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.
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.
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 :(
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.
Examples
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).
E.g.:
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
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.
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...
