This question already has an answer here:

When you begin a new project/function/object you mostly have an idea of the model you want to build. It can be based on the clients' wish, on your ideas for the app or whatever. In the middle you often realise that your model will not work. There may be new requirements, you didn't think of something etc. Then you have two options. Either you rewrite your code to work with the new specifications, or you "hack" the current code to do what you want. A rewrite is time consuming, and you may need to do it several times, but in the long run it often pays. Hacks are fast and often effective for the moment, but many hacks will make the code really bad, and after a while they may come back and bite you in the behind...

How do you determine when to do what?

(Pardon my very non-academic way of explaining this, but I hope you understand what I'm getting at.)

marked as duplicate by gnat, Dan Pichelman, user40980, Dynamic, BЈовић Jun 24 '13 at 19:01

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 6
    Some hacks may bite you in the front. – Joel Etherton Apr 11 '11 at 14:15
  • 2
    when the client catches it – Aditya P Apr 11 '11 at 15:23

Technical Debt

Hacks are not always "bad". Many times they can get you out the door and ship a product that reworking things to be the "right" way would kill the project. Building software is like building a business - sometimes you have have to take on a little debt to get a huge win in the short term at the expense of paying things back off later.

Basically, what you want to do is not just take into account how much time it will save you in the short term VS how much it will cost you in the long term, but also how much money/how many features/how many more clients will I win by doing this hack and shipping early than if I wait and let my competitor ship first.

Sometimes shipping first is best, sometimes shipping later with a better product is best, but it all depends on a lot of factors that only you can answer.

By no means am I advocating hacks in all situations. Just like any debt, it must be paid back, and intrest varies by hack such that some you can live with and others will absolutely require much more time in order for you to progress and add features after the release.

  • 1
    The problem is when you add a hack here and a hack there and before you know it your hiring ten developers to get fixing all of the hacks that are in place. Hacks are a consequence of poor design. – chrisw Apr 11 '11 at 15:12
  • True, but they can also be the consequence of the market and tough business decisions. Also, hacks vary by severity. You're right, and that's why I call it technical debt, because it has to be repaid eventually, and intrest can build up quickly over time until it can be unbearable and your team has to declare bankruptcy and rewrite the thing. – Ryan Hayes Apr 11 '11 at 15:15
  • 3
    Yes, allowing a hack or two is ok given you allocate time to fix them after the release. This will slow you down after the deadline, but may be worth it (as compared to not releasing at all). – Martin Wickman Apr 11 '11 at 15:18
  • martinfowler.com/bliki/TechnicalDebtQuadrant.html - Martin Fowler on Technical Debt: when it's good and when it's not – alexanderbird Apr 22 '16 at 7:08

You will always have to rewrite.


Sometimes sooner, sometimes later.

Plan on it. Design so that you can rewrite. Practice Late Binding and the other SOLID principles.

And rewrite as soon as you possibly can to keep the technical debt down.

In short, a "code hack" is always a bad idea.


You will always have to rewrite.

Get it over with as quickly as possible. A hack is just debt.

  • 1
    I wrote a program a few years back. It was well-written. Then I made changes, always doing them well. Recently, I took a look at it, and it needed a rewrite. Sometimes the changes add up no matter what. – David Thornley Apr 11 '11 at 17:25
  • @David Thornley: I thought did a great job writing our own home-brewed Django-REST library. Then Piston came out. I'm deleting ours. There were some issues that I now see that I didn't totally understand. I think that happens a lot. We learn and the more we learn, the more our old code doesn't look so good any more. – S.Lott Apr 11 '11 at 18:10
  • 1
    I've had plenty of experiences with seeing my old code, and realizing what I hadn't understood then. This wasn't one of them: what I wrote was generally good, and my changes were generally good, and it slowly turned into something messy. Fortunately, its good basic structure made the rewrite relatively easy, and there was a lot I didn't have to touch, but rewrites are going to be needed for code that you touch enough, no matter how deftly. – David Thornley Apr 11 '11 at 18:43
  • I can't see how late binding can help in rewrite in the future, on the contrary - I can see how it might make refactoring tedious, difficult, error prone or plain impossible. Can someone explain how it could actually benefit you? – Maurycy Jun 24 '13 at 6:43
  • 1
    Change every word in this answer to "refactor" instead of "rewrite," and it is still valid. Probably more so. – Robert Harvey Jun 24 '13 at 15:52

It's always better to redesign your solution during the design/development phase. After you release it out to clients, you will have to support it, which may involve more "hacks" or the refactoring you should have done in the first place.

If you're really pressed for time, I suppose you will have to hack something together, but do ensure that you make time later for a proper refactoring of that code. You will thank yourself and other developers on your team later by doing so.


Code hacks are fine to try an idea cause you can do it quickly and see if it works.

Code hacks are bad when you shipped them cause you will have to revisit them later or cause bugs that will cost you more later than it would have costed you to remove it in the first place. They cause technical debt.

Code hacks are insane when they actually become how things get done all the time. the debt then becomes so mindbogglingly that nobody dares to look at it and just prefer yet another code hack.

so the question becomes,

  1. do you rather suffer a little all the time but try to appease bigger pains later.

  2. or just wing it now and be the hero for a few precious minutes at the cost of big pain later.

Remember, the higher the hero's pedestal the harder the fall.


Why are new specifications being created when you are past the design stage? The specifications shouldn't change once you start to code. Being unable to modify a design to meet an system requirement is entirely different.

If you are rewritting the same system multiple times one should ask "What am I doing wrong?"

This question is to vague to actually answer the question the only acceptable answer is to avoid "code hacks" by having good specifications and acceptable designs.

  • New specs -> need to be agile... – user1249 Apr 11 '11 at 14:19
  • @Thorbjørn - I don't disagree the project needs to be agile. You also have to finish a design, having to design the same system multiple times( in different ways ), is not being agile. – Ramhound Apr 11 '11 at 14:30
  • No every project has a specification to follow. For example, I work on a lot of games, and we design the game as we go. New ideas are tried. Old not working ideas are scrapped. It's impossible to say in advance if a game will be fun. – user22675 Apr 12 '11 at 8:23
  • Agile development is from the devil. – Captain Kenpachi Jun 24 '13 at 8:29

Let’s say you have 2 options quick hack and deep refactoring. All what you need is to solve 2 equations for them:

[Total Cost of The option] = [Cost of the implementation] + [Cost of the consequences, i.e. further support, problems related with further changes]

Obviously implementation of the hack is cheaper than deep architectural changes. The challenge will be in estimation of further cost of the hacking consequences


Even in an ideal world you'd have to do this:

if cost of hack < cost of rewrite:

, which is what any sane manager would care about, but which is also so fuzzy and indeterminable as to be completely useless. This is a calculation which would be affected by everything from unknown unknowns in the development complexity calculations, via the possibility of people leaving because the code is a ball of mud, to marketing's ability to spin the decision to your advantage.

Experience might help, but expect either an enormous discrepancy in estimates or groupthink. Your best bet is probably to look for low-hanging fruit like unreadable variable names and improving the code one step at a time.


Hacks are always a bad idea. BUT if you're not the project manager, then it is not your concern whether or not the hack will need to be turned into a re-write down the line. The only thing you should have to do is explain why you need to hack something given the time/budget constraints and that you are concerned about the ramifications. Keep this correspondence on record. The PM would then have enough information to make a good decision and if he insists on the hack, HE is to blame, not you.

That's how the game works, like it or not.