How to tell a colleague that he has introduced a massive programming mistake?

Question

We are a small team of developers working on an IT project within a dedicated department. No hierarchy between us in that department, but one common goal: to get our main application up and running. We all work on the same code.

I am quite detail-oriented and take a great care when it comes to standards, clean-code and architectural concerns overall.

Now, one of the more senior devs happen to patch the code in a way that produces obvious bugs. Also, his code changes do not respect a certain quality standard. Basically, he introduces lots of bugs due to a care-free attitude, or at least a reason I cannot fathom at the moment.

The Department Manager does not care for cleanliness and operative details. He wants the main app to run and us to be able to add new features to it. He implicitly want us to take care of those details. I do think that quality standards and code maintainability is important, he has accepted that fact, but nothing is formalized in that sense. Pretty much "do as you must, it has to work I don't care how" territory.

I do not have the authority in terms of hierarchy to 'correct' the colleague. However, since he produces bugs, I want by mere friendly influence get him to avoid those bugs. I happen to hide those bugs from the manager and try to resolve them with said colleague first. He seems to be good willing but does not look like he learns. I have also in the past had verbal altercations with him since he thought I was meddling too much in "his affairs". But mostly, we get on quite friendly and have mutual respect. I might be perceived as a holier-than-thou guy, which does not help. I am nonetheless taking that mantle though, feeling the need for it.

How do you proceed to politely but efficiently help one such colleague to improve our code quality? This is mostly a communication question.

Answer 1

Hiding the bugs isn't going to do you any favours in the long run and has partly got you in this situation.

There's a couple of avenues to go down potentially:

1. Just outright tell him that there's a bug - The friendly approach may not work as he has noted you "meddle with his affairs". So if you say I have found a bug because of X, then he can resolve it.
2. Attempt to introduce code reviews - If you have freedom to implement working practices, then suggest to your team that you perform code reviews of each checkin. That way, you can review that checkin and point out the mistake in the review.

Don't fix the bugs yourself. If there is a way of logging bugs (do you have a bug tracker) then log them. You really need to try and get a manager on board to have some interest in quality of code. As you having to spot/fix your colleagues' code is taking you away from doing your tasks.

Answer 2

Everyone make bugs, pointing out bugs in someone's code is like pointing out that you had a cough. It's only natural, no matter how well we prepare you cannot avoid it 100%, thus it shouldn't be a taboo.

Likewise, since everyone make bugs, there's no point in hiding them or not talk about them with people involved and if management has to know of existing bugs then just tell them, just don't play a blaming game.

Tell your colleague about the bug. If you care about the project and your integrity as an employee then you point out that you think the bug could have been avoided by following X,Y practices, you can ask if he agrees with you or not to make sure that you know his opinions about the matter.

We found a bug in A after the latest patch, we need to fix C,D. To avoid future bugs of similar sort I think it would be good practice to do X,Y, do you agree? If not, what do you think we can do differently to avoid this?

If there are no official guidelines then there's not much you can do beside trying to suggest better practices, but if he absolutely refuses to listen and you truly believe that he is not suitable for the project because of not giving a damn in general about how he does his job then you need to bring it up with your closest manager and after that simply accept the outcome of what your manager wants to do or doesn't want to do.

If you want management to care more about code quality, however, simply give them examples on how not following certain practices could and has lead to certain bugs in the past, not only in your project but in others' and explain the impact. People don't care about things they don't understand, if they understand why certain practices must be followed then they'll be more likely to enforce them.

Answer 3

If you don't want an open discussion with the colleague, you can use his stuff in a way that will trigger the bug. What you do then, is

1. Log the bug
2. Make a test case
3. Fix the bug. Keep the test case as proof
4. Fix related issues

We don't care about that right now, you should be focused on X

This is fair criticism you might face for devoting resources to a problem that isn't a problem yet, in which case you might wanna drop steps 3 and 4 from above.

Talking to the colleague is of course the best thing to do, my answer provides an alternative to the ideal.

Answer 4

I think you're having difficulty in knowing how to say something because you feel invested in the result. And rightly so, since you two are friends and colleagues.

But I also feel that this is one of the those times you just have to let it go.

If you value your friendship and work atmosphere, then you just have to accept this aspect of your friend and move on.

Then, armed with this attitude, you can proceed to actually solving your problem.

Just tell it to him straight.

It's at times like these that I recall something I had learned in middle school: I-messages.

"I feel annoyed when you produce work with bugs because then I have to fix them. I really wish you wouldn't do this anymore."

I feel...when you...I want.

If this doesn't work, then I would change my approach to the problem, that is, I would match his attitude and let bygones be bygones because, after all, you never really know who the better engineer is.

Answer 5

Do you have mandatory code reviews? My feeling is that the answer to that question is no. If you did, that is where such exceptions should be caught, documented, and the change rejected.

Do you have an issue tracking system such as Jira? You should document your findings, include file differences, and describe how they introduce a defect. Also, describe a series of steps for how to reproduce the defect caused by the poorly implemented code change.

You should make your objection as formal as possible, and use hard, demonstrable facts, not opinions. This is not a matter of "soft skills", personality or opinions. It is a matter of easily demonstrable incompetence and you should document it as such, visible to your superiors. They should choose a course of action. In my 20 years of programming experience, admonishing a coworker over the type of objections that you have and that I have had many times, is mostly useless. But if you cannot lucidly demonstrate your case in a way that is understandable to someone of decision making power, it will likely fall on deaf ears.

If your higher ups do acknowledge your grievances, hopefully you should be able to present a case to implement mandatory code reviews as part of the SDLC, which I suspect someone of your proclivities should welcome.

Answer 6

It usually happens in products your company doesn't have to maintain, or projects where the project manager has not enough programming skills. The only thing you can do is report your project manager and your team colleagues the problems you are facing maintaining this project without complying the quality standards, and show numbers. If the client accepts this loose of money, the most probably is that nobody cares, just the person who faces the hell. If it is a closed budget project or a project you usually maintain yopur company will hear you. The most easy thing is to detect the bug and help him untill he learns enough to solve the problems himself.

Answer 7

I've tried code reviews on a couple teams, but they are a burden that requires ongoing management support. Tough to get buy in. And not infallible.

What worked for us was each developer had to produce documented unit tests. This way they usually caught their errors before deployment to user acceptance testing.

For larger complex projects we had teams of 2 or more analysts create the unit tests for the coding teams from the design/ requirements. They would run these tests for the team as a whole. That didn't eliminate unit test requirement, but added the layer needed to ensure all activities from the development team held together as a whole.

Making documented unit testing part of the process of committing code for each person on the team ensured that the seat of the pants developers used proper discipline with out singling out anyone.

Defects for the team dropped 80% or more with this discipline in place. On call support effort dropped to the point we almost never got called after a new deployment.

Test plan complexity/formality was adjusted based on the level of impact...often just a paragraph long for small changes...but expected results and actual results had to be documented (screen shots, etc).

After the success of enforcing this within our team for several years the QA team introduced this requirement to the whole IT department (they did this independently as QA matured at our company).

Occasionally we would do code reviews on new team mates or when working with new technologies. But that does not sound like your issue.

With a new application we were building, we started documenting and saving the unit test plans so they could be reused. We were using Team Track to do this. It wasn't quite the best tool, but it was better than a library of word documents. It allowed us to select which features needed testing, and we could edit the plans to document our changes. Then we could run through all the related test scenarios and document success or failure.