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"?


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.

| improve this answer | |

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.

| improve this answer | |
  • Oh so true, so very true. I've applied more bandages than I care to admit and most of them have not been fixed later. – Corin Oct 18 '10 at 20:09
  • Sometimes final release of the code contains more bandages than actual fix. Even some of the programmers started copying that bandages in other projects. – Prasham Dec 27 '10 at 5:05


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.

| improve this answer | |
  • Yesterday (Sunday. I NEVER work on Sunday, which should tell you about the kind of week I'm facing here.) I wrote a regular expression to replace the string "NaN" with "0" in a SQL statement just before it gets submitted to the server. I don't know why it's NaN at that point, and I AM interested, but I just don't have time to hunt it down. – Dan Ray Oct 18 '10 at 14:18

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.



  • 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.
| improve this answer | |

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.

| improve this answer | |

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.

| improve this answer | |

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.

| improve this answer | |
  • The if statement is not correct because the underling function if flawed. – Josh K Oct 18 '10 at 13:20
  • That may be true, but it wasn't shown in the OP - all gablin said was that a function returns an incorrect result given an input. If the function is just supposed to make a decision (like what mode the app is supposed to run in), then maybe the problem was that the if statement was missing. If the function is supposed to process a value (not choosing from a discrete set of options) then you're probably right. Without knowing more about the function and what it's used for it's impossible to say. – JohnL Oct 19 '10 at 9:43

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.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.