When do code hacks become bad? [duplicate]

Question

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

Answer 1

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.

Answer 2

You will always have to rewrite.

Always.

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.

Remember.

You will always have to rewrite.

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

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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

Answer 7

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

if cost of hack < cost of rewrite:
    hack
else:
    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.

Answer 8

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.