How to approach someone who introduced a bug to the codebase

Question

So a bit of an update to this question.

I realize I need to be more polite about calling out bad code. This scenario has come up again and I have found someone's code that has introduced a bug. Note that I have introduced plenty of bugs before and I am not the one to judge. I am just stating that this has happened again and I want to go about things the right way.

This person already doesn't like me and is already sensitive about his code. He is also a senior software engineer while I am just a regular software engineer. How should I do this? Note that we are both working remote. My honest best guess is to just message him. I know he doesn't want to hear or see this but I don't know what else to do. Let me know what you guys think.

Update: I have talked to a higher up and they have told me to go to the person that coded it. This is a person that doesn't like me and is ultra-sensitive about someone telling him his code introduced a bug (even politely). Wish me luck.

Answer 1

Follow your companies standard procedure for fixing bugs, whatever that is. If no procedure (!), raise a ticket, assign a developer (or take it yourself) and fix it. No need to make it personal. If the bug slipped through because of a gap in testing, write the tests also.

If the bug ended up visible to (and affecting) client users, write a root cause analysis if needed; but again, concentrate on the bug, not who wrote it.

Fix the bugs, not the blame. You'll appreciate that, next time you introduce an error yourself.

Answer 2

"His code" is a red flag pointing out an underlying problem in your team's or organization's culture. While fully collective code ownership isn't always possible, your team needs to accept shared responsibility for its code, independent of who originally wrote it.

This of course means that you need to be able to talk about issues you find in the code (not "his code"). It looks like trust within your team is already damaged quite a bit, so doing that in a way that improves trust as well as the actual code quality would be important. How you can approach it depends on many factors, your own personality traits, the other person's personality traits, organizational and managerial environment, etc.

I'd probably try to get a solid case (i.e. know exactly in what situations the code can fail and why) but present it tactfully and lightly, not confrontationally. Something like "Hey Bob, I think I may have found a case in which the code doesn't do what it's supposed to do, can we sit down together to have a look at the details?" (with screen sharing if you work remotely).

If the relation between both of you is broken so much that Bob does not want to listen to you, you may need to escalate this to your manager, not to point fingers at Bob but to open up communication channels and probably clear up interpersonal problems.

The ultimate goal should be that you and your teammates trust each other that you don't fear bringing up issues in your work.

Answer 3

How to approach someone who introduced a bug to the codebase

Unless code review is your responsibility within your organization, focus on the bug, not the code or the person.

Demonstrate in detail to the team responsible for handling bugs in the application how the application is broken and let the team leader or whomever is in charge decide what the next steps should be. This way, you are not accusing any specific person of introducing a bug and you are not making any commentary/critique on any specific person's code.

If you do feel it necessary to reach out to the specific individual, you follow the same mentality. Demonstrate in detail how the application is broken and let them decide what to do.

In either case, since your team appears to be sensitive to criticism (or sensitive to you), you should approach the subject as an "unexpected behavior" in the application rather than a "bug".

Answer 4

I am going to turn your problem on its head

Don't blame the person, blame the process.

Bob (your unnamed senior engineer) didn't introduce a bug into your application code, yes he wrote it. But your companies review process should have caught the bug before it allowed the bug to join the code base. That it didn't means your teams development process is flawed.

Why am I saying this?

If debugging is the process of removing software bugs, then programming must be the process of putting them in. Edsger W. Dijkstra

I have yet to meet anyone who writes bug free code for anything complicated. However with test driven development, and a good review process you can catch most* bugs before they end up in your code base.

* It is almost impossible (inside of any complex system) to prove that bugs don't exist, just that you cannot find any.

What I think you should do?

Ask why five times.

• Why did a bug get introduced into your codebase?
• Why did it get pass a peer review?
• Why was it not caught with unit tests?
• With functional tests? ... But thru all of these whys I want you to remember, its not a persons fault, it is your process's fault.

Work with Bob, and other members of your team to improve your process so that you catch bugs before they move into your codebase. Have code reviews.

Footnote

I just read your linked question... And yes, the company you are working at has a serious process problem. If you want it to change you are going to have to take ownership of the problem, and fight against a mountain of technical debt, as well as fight against a work culture which is ignoring the problem. Or you can leave for another company which will probably have similar problems.