How common are “bandage” fixes? [closed]

Question

Imagine the following scenario:

You've detected that your (or someone else's) program has a bug - a function produces the wrong result when given a particular input. You examine the code and can't find anything wrong: it just seem to bog out when given this input.

You can now do one of two things: you either examine the code further until you've found the actual cause; or you slap on a bandage by adding an if statement checking if the input is this particular input - if it is, return the expected value.

To me, applying the bandage would be completely unacceptable. If the code is behaving unexpectingly on this input, what other input that you've missed will it react strangely to? It just doesn't seem like a fix at all - you're just shoveling the problem under the rug.

As I wouldn't even consider doing this, I'm surprised at how often the professors and books keep reminding us about how applying "bandage" fixes is not a good idea. So this makes me wonder: just how common are these kinds of "fixes"?

Answer 1

Time/deadline pressures are one reason.

If you are up against a tight deadline and you've got your boss breathing down your neck (possibly literally!) then doing this and thinking "I'll come back and fix this later" is very tempting and might be the only thing you can do.

Of course the number of times you actually go back and fix it properly are very few and far between because you have a new problem that needs fixing yesterday.

Answer 2

As much as we as programmers don't like to admit it, beautifully coded software isn't always going to translate to more value to the company or the customers. This is doubly true in a disaster situation, for example the software is double charging people's credit cards. Sometimes, like a bandage, you just need to stop the bleeding by whatever means necessary and promise to get back after the patient has been stabilized and actually fix the core problem.

The trick is, that once the urgency is gone, it is really hard to convince anyone to prioritize replacing the bandage with a true fix. Especially considering that there is always another urgent issue waiting in line behind the first one. You just have to be vigilant about staying with the issue beyond the quick-fix.

Answer 3

Time

Is the #1 reason in my opinion. Although if the problem is codebase wise I might take more time to investigate it. Often my "bandage" fixes involve CSS or UI tweaks. I've written some pretty nasty inline CSS and JavaScript to deal with them quickly. Going back and fixing it is always an option if you get the time.

Answer 4

We do them exceptionally.

---

For fixes during development, we are making sure that no fix is done without knowing the root cause. However:

• Exceptionally the search for the root cause will start to take too long or stall AND there is a tough deadline,
• Exceptionally code changes to fix the root cause are tactically not feasible (change will take too long and deadline approaching)

In those cases we opt of "bandage" fixes. We then open internal defects to address the root cause. Yes, more often than not these internal defects are treated with very low priority.

---

For fixes in the maintenance stream, we are making sure that no fix is done without knowing the root cause. However:

• Very exceptionally the search for the root cause will stall,
• Exceptionally it can occur that fixing the root cause is tactically not feasible (change is non trivial and customer needed the fix yesterday).

In those cases we opt for "bandage" temporary fix first and once customer is happy we work on the proper fix and only then the defect is resolved.

Answer 5

Disambiguation.

• Given a particular bug, there is considerable difficulty in objectively defining whether a particular fix is a "bandage" because: one's "correct solution" may be another person's "bandage".
• So, I use the following definition: to fix a defect in a manner that is less elegant and less well-studied than I wish I would have done professionally.

---

First, regarding the frequency of "bandage" fixes:

• New code: almost none.
• Old code:
  • You will find some, although they are usually written elegantly enough (see "data-driven mitigation" below) that they don't look like bandages and will survive all code reviews.
  • Also pay attention to the "invisible bandage": simply don't call that function. With the lack of code, there is not even a trace of hint that a bug exists.
• Old code with many external dependencies:
  • Almost full of it.
  • It was almost always written for an obsolete version of the dependency, and nobody really read the dependency's "release notes" before updating the dependency to a new version.

---

Second, my advice:

If the bug happens in a development team's own source code:

• Fix it in a professional way. (If you fix it, you own it.)
• When under time pressure, do the best things you can - which requires you to:
  • Look at the potential impact on the end-user: of the bug itself, and of the proposed fix, in order to decide whether to accept the fix.
  • Study related code snippets (using the history info from your source code management tool), and discuss with your coworkers (but don't occupy too much of their time), until you have well understood the problem and the solution.
• Always track the bug with a defect tracking system.

If the bug happens in another team's source code:

• Push that team to fix their bug.
• Always file that bug with the other team's defect tracking system.

If the bug happens in another company's (or no company's) product:

• In this case, duct-tape fixes (or data-driven workarounds) might be the only way to fix the bug.
• If it is open source, file that bug with some (possibly public) defect tracking system anyway, so that someone can look into it.

Answer 6

Depends a lot on the age of the code base I think. On old code I think it is very common, rewriting that 20 year old COBOL routine is not fun. Even on moderately new code that is in production it is still pretty common.

Answer 7

I would say it's very common.

Check out Joel Spolsky's blog post: The Duct Tape Programmer

I can easily say that just about every project I've ever been on I've had to apply some kind of bandage or duct tape to meet deadlines and complete a task. It's not pretty, it's not clean, but it gets the job done so a business can continue to run, and the project can move forward in some way.

There's a difference between the academic world, and the real world where software actually needs to ship under time and business contraints.

In a way it is putting it under the rug, to defer a fix, until hopefully, later. Sadly, too often, the deferred fix never happens and this code finds its way into production.

Answer 8

It's difficult to say without more context - in your example, why is adding the if statement not the correct fix? Is it because there's supposedly some other block of code in there somewhere that is supposed to be dealing with that input?

How often bandage fixes are used depends on a number of things such as how complex the code is, whether the person most familiar with the code is available (the person responsible for Craig's 20-year-old COBOL routine may have left the company years ago) and the timescales involved.

With a deadline staring you in the face, you will sometimes plump for the safer fix, even if it is just slapping a plaster on rather than fixing the root cause. That's ok as long as you don't make things worse, but it's important to track the fact that it's still not correct and still needs to be fixed properly.

Answer 9

There are cases where that kind of fix is really OK and probably the ideal (as far as the amount of time it takes to debug is concerned).

Imagine a scenario where you've got 20 DLLs which are supposed to act as some sort of modules for your main executable, but also require some information from the main executable to run.

If you ever want to use those DLL's outside of the main executable, you will need to fudge some return values from the main executable because. A.) It doesn't exist in this context and B.) You don't want it to exist in this context.

That being said, you better put some compiler directives in your code to make sure you're running completely different code when you're fudging the results vs when you're getting the real results.

Instead of putting an if inside someone else's function, I'd put an {$ifdef} around the function - that way no one confuses it with something that ought to be there.