Diplomatically point out the obvious problem in a product

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.