Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

As we all know, every software has bugs in it. It is matter of time to discover it.

Suppose if you just found your product has potential big issue and it was not developed by you.

How would you deal with it?

I usually speak up with some data & analysis even if it is not my part of code. I am wondering if it is too offensive because I often faced on some resistance(depending on the issue), which would eventually be gone.

share|improve this question
Much depends on your seniority and how well you know the people that you work with and how much they like you. You might be able to tell anyone (after doing some hw), or you might want to proceed carefully. Usually the best person to talk about an issue is the person who has created it. –  Job Dec 6 '10 at 23:15
Thank you for all your answers. This task is really challenging for me. –  exiter2000 Dec 7 '10 at 15:32
A bug can also be a changing requirement. –  user1249 Apr 2 '12 at 14:35

8 Answers 8

up vote 9 down vote accepted

For "big issue not developed by you" it is not up to you personally to figure out how to handle this issue, so it automatically implies you need to bring it up with your immediate superior, along with an initial estimate of the severeness of the issue.

If at all possible up front also a suggested way to fix it - preferably also with an estimate.

The reason for this is that "big issues" may result in quite a bit of work to fix, and perhaps even cause schedules to slip if you need to redo a lot of testing etc. Hence it may well be declared a "known issue" to the users and not fixed yet, to keep on schedule.

But to reiterate, bring the issue to the attention of your organization.

EDIT: Also, coorporate culture should encourage that code is not owned by an individual but everybody. This means that it is not a blame game, but a common responsibility to find and fix. If somebody consistently produce sub-standard code, it is time to introduce code review to catch as much as possible as early as possible.

share|improve this answer
Would it be deplomatic enough? You know, some developer took it personally. I would like to avoid it –  exiter2000 Dec 6 '10 at 22:29
@exiter2000: Somebody will always take something personally. That doesn't mean you shouldn't try to be polite and considerate, but that if somebody takes offense it isn't necessarily your fault. –  David Thornley Dec 6 '10 at 22:33
Personally I would expect that co-workers who see a - potential - big issue in code, call attention to the fact. Calmly and profesionally bringing it to your superiors attention - and especially if ther is a bug - is in my view the proper way to handle this. –  user1249 Dec 6 '10 at 22:35
+1: you might also want to mention it to the author of the offending code first in a collaborative tone. Something like: "Hey, had you noticed in module [x] that there is a potential for [y] to happen in [z] circumstances? I think it's pretty serious and you and I should bring it up with the boss." This way, you're solving the problem, with the author, and not even going near the blame game. –  Steve Evers Dec 7 '10 at 1:45
@SnOrfus, perhaps. I would think this is one of the situations where you cannot generalize ahead of time. –  user1249 Dec 8 '10 at 21:14

I've found that the diplomatic way to point out an obvious bug is to refrain from assuming that it's an obvious bug when I point it out.

What I generally do when I find an issue like this is talk to the guy who wrote it in private. I run SVN Blame to see who set it that way, then I go to him. "In file xxxx on line ###, we've got some code that does X and Y. That sorta looks strange to me; it feels like it should do Z in this situation instead. Now you're the one who wrote this, so is there a reason behind this or is it just an oversight?"

Usually it was a genuine bug, and one or the other of you ends up fixing it, but sometimes there's actually a good reason for what you originally think was an "obvious problem," and if you approach it this way there's a pretty good chance that you'll get a reasonable explanation for it.

share|improve this answer
Ah, figuring out the "why"s. Important. Both to figure out and to add a note in the source for the next bypasser. See stackoverflow.com/questions/184618/… –  user1249 Dec 8 '10 at 21:17
+1. If it's a genuine bug, you've brought it to the guy's attention in a very diplomatic way. If not, you've learned something without embarrassing anybody. –  David Thornley Dec 9 '10 at 21:30
Heck if code looks like it's a bug, and a icky one I'll ask everyone in the project team to look at it; maybe I'm not seeing something, different people look at things different ways. If the dev responsible is still with your company, lucky you. I find the change history for the line in question can be very informative. –  Tim Williscroft Dec 10 '10 at 0:44
@Tim: Yeah, most of the time the dev responsible is still around. Our core team is pretty stable. If not, I tend to just figure it's a bug and fix it, or show it to one of the senior developers if I'm really not sure. –  Mason Wheeler Dec 10 '10 at 17:25

I have always found that pointing out or asking about things that I see as issues is a good thing. Many developers have their ego's wrapped up in their code so at times it can be uncomfortable but if you do it nicely you can gain the respect of even the person who wrote the code. One of the following will happen:

  1. The problem will get fixed and everyone learns from it.
  2. There wasn't really a problem in the first place, you just misunderstood it. Everyone learns from your questions about it.
  3. The problem is documented but left the way it is. Everyone learns not to do it this way in the future.
  4. You get in trouble. You learn that this isn't the place you want to work.
share|improve this answer
There's also #5: The author insists it's not a bug, and you keep going back with more evidence and saying how you think it should be fixed. Then one day, instead of telling you again why it's not a bug, he reworks your last email and sends it out under his name and takes credit for finding and fixing the bug. –  Bob Murphy Dec 10 '10 at 7:01
@Bob... ah yes... but as long as you know it you've both then learned something. They about programming... you about the ego. –  Beth Whitezel Dec 11 '10 at 5:28
I was about 50 at the time and knew very thoroughly some people had that kind of ego. I just didn't know he was one of them. I was mostly asking him about it because he was the original author and I was trying to be courteous. What I really learned is that when you show somebody clear evidence of a bug, and they say, "You must be wrong. There can't be a bug in that code because I wrote it," they don't deserve any further courtesy around that bug. –  Bob Murphy Dec 11 '10 at 17:14

The first thing is to understand the genuine scale of the issue. If an issue has existed for any period of time there is a good chance that it's not as big an issue as some might make out. I've had people bring me "critical" issues that have been in a live system for two years - with respect if it's been in the system with no-one reporting it for two years there is a fair chance that while potentially significant it's not that critical.

After that as you say a full analysis of the problem with an assessment of the consequences (impact, probability of it occurring).

Then options for fixing it (ideally a range - if it's that big you may want an urgent quick fix then a more permanent resolution) with estimates.

But the most important thing is the tone you use to raise the issue. It shouldn't be critical, it should be about improving things and you should be sensitive to those who've worked on the system for a while and not look to point blame. Even if the person who wrote the bad code is there it may be that he or she had their backs to the wall on an impossible deadline and never had the chance to fix it so never assume incompetence.

share|improve this answer
You make a good point, but remember that just because a big issue hasn't bitten anyone yet doesn't mean that it can't make a really big mess when it does. I've seen critical issues reported by clients and it turns out that the offending code has been around for years and years and it's just that no one used that feature in quite that way yet. But once they did... KABOOM! –  Mason Wheeler Dec 6 '10 at 23:01
@Mason - That's why I say understand the genuine scale. Developers have a habit of seeing things which are technically unpleasant and over stating their significance. I'm not saying that they're not issues, just that a good assessment is critical. –  Jon Hopkins Dec 7 '10 at 7:49

My approach if I run into what looks to me like a serious problem that falls outside my remit is to ask about it. Or try to ask a series of questions that will lead someone who already understands the code to see the problem. That way I'm not actually bumping into someone else's territory and if it's done with a bit of subtlety it's not even clear that I was aware of the problem, it's just a conversation that happens to end up with a useful outcome.

share|improve this answer

I guess this would be much more diplomatic - Find out who the developer is (using your source control system), talk to him regarding this bug. Work together to find out if it's a bug and the severity if its left unnoticed. Then go to your supervisor along with that developer and discuss the issue and ways to solve it.

share|improve this answer

How about e-mailing the developer? And you can add all the diplomatic smooth-talk you like, as long as you point out the problem because neither you nor the other guy are in the office to practice politics or diplomacy, you are there to solve problems by writing software.

share|improve this answer

If there is a significant bug I will often get the programmer and rub their face in the code while telling in a firm voice "No. Bad programmer. This is not how we write code." Make it clear to them that the software they've produced is not acceptable.

However, it shouldn't get to this point. Through the use of positive re-enforcement you can encourage and instill good behaviors. A complement when they write a test, a soda treat when write clean maintainable code, these small daily rewards can help give you the programmer you've always wanted.

share|improve this answer
How to Raise the Perfect Programmer: Through Puppyhood and Beyond. :P –  Matthieu Dec 9 '10 at 20:12

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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