Are all dirty fixes created equal? [closed]

Question

I have seen some dirty code in my time. I have heard varied feedback about "dirty fixes" too:

a) a dirty "fix" is not a fix

b) some fixes dirtier than others but dirty fixes are not acceptable

c) some fixes dirtier than others and some dirty fixes are more acceptable than others

d) dirty fixes show a pragmatic use of ones time but should be discouraged

e) dirty fixes show a pragmatic use of ones time and should not be discouraged

f) other

Which of the above would you agree with and why? How do you stop attitudes like (e) from becoming standard practice?

Answer 1

A 'dirty' fix is a form of Technical Debt and whether you can afford it is ultimately down to a cost/benefit analysis.

With apologies to Olve Maudel who (in a lightning talk(p3) at the ACCU conference) may have said something not completely unlike the following, compare:

• The immediate cost of fixing a bug properly + the immediate cost of not having it fixed in time

vs.

• The immediate cost of a dirty fix + the ongoing long term cost of the dirty fix

If fixing it properly, means that you miss a deadline that would have got you a staged payment, or means that a competitor gets to market before you, then that cost could be quite high and it may have been worth incurring the technical debt instead. But remember that the longer you leave that debt unpaid, the more interest you are going to accrue in terms of the cost of supporting the code and adding new features. In some circumstance a dirty fix may be the pragmatic solution.

Beware though, if you use being pragmatic as an excuse for laziness and keep on racking up the technical debt, never paying off earlier debt through re-factoring, you may find that the debt rises so high that bankruptcy is the only remaining pragmatic option. *8')

Answer 2

It's true that a dirty "fix" is not a fix (a). If a product has a problem, a clean fix is intended to fix this problem to be able to:

• Reuse the concerned part of the product and be sure that there are no known issues with it,
• Don't have to return to modify code again later to solve bugs.

With a dirty fix, the developer:

• Can't reuse the concerned part, because she cannot be sure that it will work as expected,
• Must return later to rewrite the code correctly.

So instead of spending more time fixing something, a dirty fix is used to spend less time immediately, but more time lately by forcing to return and make a clean fix and by forbidding to reuse code meanwhile.

---

Of course, this may not apply to every dirty fix, and it also depends on what we call a dirty fix or not. Example:

A user submits a report saying that a program gives an incorrect result when the input is equal to 39.5. A stupidly dirty DailyWTF candidate fix would be to do:

if (input == 39.5)
{
    // 14.7 is a correct result, calculated by hand.
    output = 14.7;
}
else
{
    // Keep the old and broken algorithm.
    // ...
}

Chances are that in a few days or weeks, another report from another customer will tell us that the output is also incorrect for some other input value.

A less dirty fix would be to check the algorithm, see where is it broken, and fix it, without fixing the unit tests. The chances to see it break again are smaller, but it can happen, and there is a need to return later to add unit tests, maybe add comments, enforce style guidelines, write documentation, etc.

So yes, some fixes dirtier than others (b, c). If some are more acceptable than others is up to your company guidelines.

---

Dirty fixes show a pragmatic use of ones time (d, e). At a precise moment. Because by spending a few minutes less, you waste hours of your own time lately (or your colleagues will spend later hours cleaning your fix). That's why dirty fixes should be discouraged especially in a team. If a developer makes lots of dirty fixes, then leaves the company, the other people of the team will have hard time cleaning the fixes.

---

How do we stop attitudes like "dirty fixes show a pragmatic use of ones time and should not be discouraged" from becoming standard practice?

By enforcing best practices, but also by ensuring that the developers in a team/in a company communicate well about what they're doing. Too much pressure and stress from management can also force the developers to use more dirty fixes just to finish quickly. This is especially true when the team manager is inexperienced enough and/or don't care about code quality.

Answer 3

Depends on context.

I've certainly put in some horrible fixes in my time, but the code I was working on was beyond redemption - a complete mess of PHP that was copy/paste mass of dependencies everywhere (with variations) and the most random database "design" I've ever seen. Of course I'll never willingly show that code in support of a job application!

Normally I go with a) At the very least what I do should be understandable and maintainable. If I can improve/refactor a little at the same time, so much the better.

d) and e) are simply lazy... you may save 30 minutes now, but what of when the next update / fix is needed in six months? It's false economy.

Answer 4

In general hacks/dirty fixes should be avoided and rejected. There are exceptions though.

1. If the framework/language is too limited to do it properly without massive project restructure.
2. If the framework/language has a bug that must be worked around
3. If there is no foreseeable way to actually cleanly fix the core problem(related to #1)

For #3: For instance, I've done some very odd things working around ASP.Net's crooked page lifecycle. I understood exactly how every event was called and why my code wasn't working. So I ended up calling _Click methods manually by checking the Form array myself earlier in the page lifecycle than events are normally called.

For #1: I had a SQL query being built manually so it ended up being like

query="select * from table where";
if(Option1){
  query+=" option1='"+Option1String+"' ";
}
if(Option2){
  query+=" option2='"+Option2String+"' ";
}
if(Option3){
  query+=" option3='"+Option3String+"' ";
}

So it ended up that if none of the options were selected, I'd get a syntax error. My other option was to constantly build a if(Option1 | Option2 | Option3) which I thought to be a maintenance nightmare for when options were added. So I fixed it with a single change:

query="select * from table where 1=1";

I'd consider this dirty/a hack because it's not immediately apparent why 1=1 was put there. I of course commented the hell out of it explaining it. But it's still a hack. The alternative "proper" way was harder to maintain however.

Answer 5

A "dirty" fix is a fix; otherwise, wouldn't it be a break?

I think the question of whether a "dirty" fix should be unacceptable or discouraged presumes that there is a clear distinction between a "dirty" fix and a "clean" fix, and I don't think there is. I have applied fixes I thought were "clean" that ultimately proved to be "dirty" compared to the next fix. (Less often, I have applied fixes I thought were "dirty" that ultimately proved quite "clean"). I think it would be more valuable to distinguish between a "dirty" fix and a "dirtier" fix, with the former being preferable, all else equal.

Both the "dirty" and the "dirtier" fix should resolve the immediate issue, but when compared to the "dirtier" fix, the "dirty" fix should reduce the likelihood of future error and, should an error occur, reduce the effort required to resolve that error. That might require as much as refactoring the code, or it might require as little as documenting the code and logging its execution, so that the next developer might be better able to diagnose and fix the error.

As for how to discourage developers from choosing the "dirtier" fix, I'd say, stop encouraging developers to chose the "dirtier" fix by explicitly preferring the faster fix and thus implicitly preferring the "dirtier" one.

Answer 6

In general, a "fix" or a "hack" is a bad thing. And in school we learn how to not do fixes. But in real life, when time is of the essence, fixes happen like constant Id's in code, not making the code general enough e t c. As long as everyone from the project agrees of what is beeing done, I think it's OK. The risk is that the code will not be changed later on to be corrected. The risk is that one is building a labyrinth of code which will be harder and harder to correct the longer the fixes stay. Also time to change fixes increases logarithmic the longer they are allowed to stay in the solution.

So I agree on c) and d) if possible - meaning if you need to do a fix, comment it well and make the code simple enough for the next programmer, who might be the one to correct the fix. Then you have made the most of the current situation.

Answer 7

I lean towards f) with a good dose of d) and c).

If the next version of the code is being actively developed, a dirty (quick) fix may be an appropriate action on the production branch. The fix should be as clean as possible, and certainly should not qualify as a DailyWTF candidate. It may allow you to fix the production branch in cases where the clean fix will need more work than is practical.

If you do use a dirty fix, it should not be merged into the development branch. With few exceptions (dropped features), all production fixes should be applied to the development stream. If you can apply a clean fix, merging it onto the development stream is appropriate. If not, the fix should be redone cleanly on the development stream.

Answer 8

Question is largely academic. Most often, in a production environment, there's no time to do things "clean" when a problem appears on a production system. Thus you take the fastest route to fix the problem, thus limiting downtime as much as possible. That might be a "dirty fix" in that it's not the best looking of code, but it gets the job done which is far more important as downtime means lost revenue, code that doesn't look nice just means lost brownie points for programmers' egos.

If it's a real hack, you're probably going to tag it for refactoring at the earliest opportunity (i.e. when that part of the code is next scheduled for change, NOT in the next release just because you want to get rid of it), but it will go in now because there's simply no time to do things nicely.

Such is the world of deadlines, working to real world requirements rather than homework assignments.

Answer 9

My view is that there is never a good reason for a dirty fix, only excuses that hint at a larger problem. Sometimes that problem is something you can't fix (e.g. no management buy-in, issue with the framework/language you are using) but it's still always an excuse to cover up something else.

Not surprisingly I try to avoid doing things the "dirty" way whenever possible, since my experience is that you never will be able to fix it properly and "pay back" the Technical Debt.