Improving software when the author can see no need for improvement

Question

I have a coworker who has been practically the sole contributor on a service for a number of years. For the most part, he does an above-average job. It works fairly reliably, it is thoroughly tested, and is relatively easy to read on a line-by-line level.

The software also has a lot of room for improvement. The details don't really matter to this question, but the flaws are completely uncontroversial to others I have discussed them with. Things like parsing a highly-nested grammar with regular expressions. He also takes decoupling to the extreme, to the detriment of other equally-important design principles.

These problems have built up over time, to the point where making changes now takes significantly more time than anticipated, and my coworker really needs help to keep the backlog from growing.

The problem is when anyone else tries to help out, he takes the changes personally, gets very defensive about his code, has difficulty admitting there is anything wrong with his design, and blames problems on user error or on code other people wrote. In other words, he seems completely blind to flaws in his code.

He is kind and pleasant about it, but also very stubborn, and will stand his ground for days, despite multiple people disagreeing with him. If we approach him before we make the changes, it's even worse, because he has a hard time visualizing the result. We don't technically need his permission to make improvements, but it is the courteous thing to do.

It is a draining process for everyone involved, and frankly, I don't want to spend the energy anymore. How can I approach making improvements to his code without having to argue (politely) for days to get it merged?

Answer 1

How can I approach making improvements to his code without having to argue (politely) for days to get it merged?

Based on the text of this question, you seem like a very reasonable person and have done the necessary things to try and be inclusive and considerate of the other developer when introducing new techniques.

At this point, I think you should bring this to the attention of your manager. You should not have to debate every single commit, especially when the approach is clearly better.

You have already tried working with the individual directly, and it has proven exhausting. Let your manager deal with this going forward.

Answer 2

How can I approach making improvements to his code without having to argue (politely) for days to get it merged?

Don't approach him anymore when making improvements to the code. You have already attempted this on multiple occasions and the results have not been desirable.

At this point, since you stated that his permission is not needed, simply go ahead and work with your coworkers to improve the code when necessary. Don't attempt to re-write the whole program, only modify and improve the code necessary for your specific task.

I wouldn't mention anything to the coworker until after the changes are complete and thoroughly tested and you can demonstrate that the new code is an actual improvement. This is very important, the code you and your other coworkers write has to be better than the original otherwise you not only upset the coworker but you lose credibility.

Answer 3

You should consider issues of (a) preference and (b) performance separately. The couple of issues you describe (using regex for parsing, or putting a priority on decoupling) may be more in the camp of composition preferences and not major performance limiters.

In both cases though, you should focus on the value at stake (how many hours or headaches or dollars would be saved by a change) and avoid criticizing existing implementations, regardless of how bad they may be.

Also realize that tech debt is undesirable, but it happens in every team and fixing it can be a substantial cost. Sometimes it really is better to leave things as-is even when you have to constantly create work-arounds.

---

(a) For issues of different preferences, it's good to describe the alternatives you think of, but your colleague likely gets the final say on how the package is composed. You should also make clear that your suggestions are your own preference, and not an objectively better way to compose code. Even where highly-opinionated standards for composition have been created (e.g., PEP-8 & Black), these remain opinions and may not be a good fit for the problems your organization works on. Debating preferences as peers will be a far friendlier approach than criticizing the preference of your colleague.

---

(b) For issues of software and/or team performance, it's also good to suggest alternatives, but take some reasonable steps to ensure your suggestions are productive:

1. What is the quantified performance impact? If an alternative to parsing with regex runs 100x faster, how many hours of compute would be saved over the course of a year?
2. What kind of effort will reworking take? Multiply your estimate by 3. And now that you know you're going to multiply by 3, you might be biased low, so multiply by 3 again.
3. How relevant is the performance of the section of code to the needs of your customers? Do your customers care about performance (whether in processing latency or cost)?
4. How does your performance improvement idea compare to other improvement ideas? There are likely a lot of ideas in the "parking lot" for your team - is this performance improvement substantial enough to become the priority?

With those questions answered, you could propose the idea to your team.

Answer 4

Assuming you're both at the same seniority: If a guy told me that I'm changing his code the wrong way (and I know for sure I'm not), I'd tell him to fix it his way. Then when he claims he doesn't have the time I'd politely tell him to stfu. You're stretching the problem out by treating him like a delicate flower. Or option two: Just stop helping him 100%. Get your co-workers to do the same. Then his problem of not being able to fix his code in a timely fashion will definitely rise to management. When management asks why you aren't team players, you all point fingers at him. Honestly this guy should have been fired years ago. Your manager is asleep for sure. Even the most hands off manager should be aware of how long it's taking to fix this guys code.

If he out ranks you that's another story. Time to look for another job, perhaps.

Answer 5

First of all

• It is your opinion that his design and code is flawed.
• It is his opinion it isn't.

Opinions make trench wars and unhappy colleagues. You need to make it measurable. Tools exist that can analyse code and extract things like depth of hierarchy, test coverage, etc. Find a tool that can measure what you think is important and make the team agree on what should be done and use the tool to see you get there.

Perhaps you can analyze why bug-fixing currently takes so long, so you can help him improve where he actually wants to improve. You might be wrong in your assumptions.

Answer 6

To play devil's advocate, has anybody that disagrees with your colleague attempted to understand their point of view?

They have worked solo on this project for years (did anyone express interest before now?) and now, despite having a reliable, heavily tested product with easy to read source code, people want to undo their code because they think their code is better.

If your colleague is unable to visualise the result, then you're failing to communicate the idea within the context of the product. Remember, this is something that they've been thinking about for several years, they know it inside and out.

The solution to this issue is a simple 4 step method:

1. Suggest (make your suggestion);
2. Listen and acknowledge (listen to their response);
3. Negotiate (find a compromise);
4. Action (enact the compromise).

To be perfectly honest though, if I'm reading the situation right from the question, you probably won't have to worry about the colleague for much longer as they are probably already planning on changing employer as the environment would be feeling very much "anti them".