I recently made a change that caused some code to be run far more often than it used to. This lead to the discovery of a bug. This bug had the potential to happen any time that code was run but because it was run so seldom it never surfaced.

When I brought this to the lead developer's attention he wanted me to undo the change that exposed the bug rather than fix the bug quoting the adage, "If it ain't broke, don't fix it".

Its clear to me that we were just lucky up until now but he won't listen to reason.

Should I fix it anyway?


The lead technically doesn't have any authority over me. Just tenure. He's been the sole developer on the project for a number of years until a year ago and I think he doesn't take constructive criticism very well. For what's worth, I didn't criticize him. I just pointed out that just because the bug never showed up didn't mean it wasn't there.

  • Is it a threading related bug or something else? – TheLQ Jan 11 '11 at 22:18
  • 3
    He's the boss for a reason. When the poop hits the fan he will be the one they roast. If he gets roasted because you did not do what he asks then you will need a big paddle. – Martin York Jan 11 '11 at 22:31
  • 3
    Can you construct a case where the bug occurs even with your change undone? If not, maybe it's not a bug, it's a fea^H^H^H^Hn undocumented limitation. – Steve314 Jan 12 '11 at 2:30
  • 3
    Hmm, "If it is broke, unfix something else." - well it's a novel interpretation, I'll give him that. – Orbling Jan 12 '11 at 3:24
  • 1
    "If it ain't broke, don't fix it"? But it is broke. – StuperUser Jan 12 '11 at 16:17

I would suggest that if you have bug tracking, then submit it. If it's critical then elevate it and bring it to his attention. Let your superior demote it in the tracker. When things go wrong, you'll have the paper trail.

  • 9
    Remember: Cover Your Ass :-) – gruszczy Jan 11 '11 at 22:28
  • 1
    Not so lucky. Everything is seat-of-the-pants. No bug tracking, no requirements gathering, no testing. Probably wouldn't even have version control if the management didn't insist on it. – Kenneth Cochran Jan 11 '11 at 22:30
  • 18
    Based on your description of your working environment, you should have nodded and smiled when the lead dev told you not to fix it, and then gone ahead and done what you wanted to do anyway. – Carson63000 Jan 11 '11 at 22:31
  • 2
    And don't ask such questions next time :-) – gruszczy Jan 11 '11 at 22:37
  • 2
    @codeelegance: "No bug tracking, no requirements gathering, no testing. Probably wouldn't even have version control if the management didn't insist on it." - Sweet Maria Mother Of God!!1!! That environment stands in stark irony to your username. :) – Bobby Tables Jan 12 '11 at 3:22

Personally I would fix it, unless it required a significant amount more effort than it was worth. "If it ain't broke, don't fix it" is horrible to apply to software.

If your lead developer is your boss and he says don't touch it, in that case I would not.

  • 2
    How late in the cycle are they? This could be a potential suicide. – Job Jan 11 '11 at 22:46
  • 8
    "If it ain't broke don't fix it" is a perfectly good rule to apply to software - just not when the software is broke. – Steve314 Jan 12 '11 at 2:27
  • If it aint broke don't fix it applies to software depending on what the definition of broken code is. The very moment you sit down and stare at code that obviously needs to be fixed, it becomes broken. The very moment you start implementing workarounds for broken code, you are actually working backwards and in time the broken code will be harder and harder to fix... – Ernelli Jan 13 '11 at 12:06

Most of the answers and comments suggested mitigating responsibility for the decision by creating a bug report and letting someone else make the call.

Since I don't have bug tracker (and I doubt anyone other than myself would use it if we did) I did the next best thing. I went over the lead developer's head. After explaining the situation to management they saw things my way. They told me to fix it properly and ignore the lead's demand request. They said they would smooth any ruffled feathers if he ever discovered the subterfuge and complained.

Not an ideal solution but at least the bug was fixed properly.

  • You worked within the chain of command, and as such covered your butt. Using bug tracking software is something your company should consider, it helps at least keep track of stuff like this, and feature requests, etc. – Berin Loritsch Jan 12 '11 at 15:21

Remind him the phrase is, "If it ain't broke, don't fix it" and not "If the client hasn't noticed it, don't fix it".


What justification do you have for the change you made? If you can't point out what changes the user would experience or technical debt has been removed, I would side with the lead developer in terms of saying just back out the change as this is just making things worse.

You have at least a couple of different options here to my mind:

If you just go ahead and fix the bug you risk adding more bugs to the mix which could backfire to my mind. Depending on how much experience you have and confidence of avoiding some nasty surprise that would likely be my guide here.

If you do what you were told to do, is it just guilt that would be the problem or is it more than that? I'm wondering what is wrong here other than that stuff known as principles and values. I mean that as a bit of a joke but also an honest point of what is wrong with this idea?

  • The change was necessary to fix another bug. The lead suggested I put conditionals that limit how often the code is run rather than fix the cause of the bug. Both the bug I fixed and the one I uncovered are show stoppers. – Kenneth Cochran Jan 11 '11 at 22:27
  • 3
    In that case it needs to be properly fixed. Using conditions wrapped around a problem merely defers the catastrophe, AND it adds more new code which is more to go wrong. Its a bad (even a silly) solution. – quickly_now Jan 12 '11 at 8:15

Whilst my overwhelming instinct would be to fix the bugs not hide the problem, there are scenarios when i would hold my nose and hide the problem.

  1. Code is used internally, and occasionally, so the consequences of the bug are manageable inside the company.
  2. Overwhelming commercial considerations that demanded shipping today, and a bug fix could be rolled out 2 weeks later with minimal consequences.

Professionally, I don't like these answers, and would be making it clear internally that ether of these situations were occurring.


Ultimately, you should not do anything that your superior explicitly said not to. I believe that the best thing to do in your position is to create a bug report in whatever bug tracking database you have. this way at least everyone is aware of the issue and someone with more authority can decide what to do with it.


Copy the buggy function, apply the fix, rename it, maybe disguise it a little, and call that instead.

Based on your two showstopper bugs comment, your best choice may be to follow the letter of the law, but ignore its spirit.

Obviously there's a cut-and-paste coding downside, but it sounds like that will be the least of your problems.

  • 1
    bad idea, if i'd caught one of my programmers doing something like that, i'd fire him on the spot, that's a guaranteed way to cause damage to the code and for anyone who has to maintain that code. – Miki Watts Jan 12 '11 at 12:01
  • @Miki - in this case, tell me exactly what isn't a bad idea? Please explain how putting a bug back in because it made another bug (that was there anyway) more visible is a good thing. As for the firing on the spot thing, I'd argue constructive dismissal, as the developer was left little choice. – Steve314 Jan 15 '11 at 1:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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