10

In our software development group, another developer, not standing higher in the hierarchy, keeps rewriting significant parts of the code I contribute.

The code being rewritten works as expected, is covered by passing tests and does not have very obvious deviations from the coding rules (these are rather purely defined). The code becomes much more sophisticated after rewrites, with multiple layers of indirection and often "better" implementations of functionality than is provided by the standard libraries. These changes are never discussed with me in advance, while they of the kind reviewed and discussed with somebody else within the team. The team is split between the two departments, and the co-worker can always find developers closer to him for discussion and approvals.

The developer claims that rewritten code "has the better design". This may be true to some degree, as this is the second iteration, based on experience of the first iteration. Still, he is not doing other tasks at this time. The project lags behind the schedule significantly and I am afraid to stay responsible for this. Also, I do not always think that the rewritten code has better design.

One of the possible solutions would be to escalate to the management, but this is my team, the people I work with and would likely need to work in the future. I could provide lots of samples proving that another developer is not as good as he thinks, sometimes lacking understanding even about the basic data structures, like list or map (or having no experience in the programming language used?). However I do not want to enter into confrontation that would be ended by one of us being fired or forced to leave the team. Is there any other approach to the problem?

closed as unclear what you're asking by JasonJ, gnat, Chris E, Michael Grubey, Rory Alsop Apr 14 '17 at 0:08

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 26
    If he's wasting his time by "optimizing" your code, let him go on. Let him hang himself. Hand him the rope. Constantly wasting time with unnecessary stuff whilst abandoning one's current tasks is one of the fastest ways to get fired. – Seth Apr 12 '17 at 8:29
  • 5
    Adding to @Seth's comment, sooner or later he will introduce a bug with his rewritings. I'd really like to see his defense when that happens. – BgrWorker Apr 12 '17 at 8:58
  • 3
    Is code review practised on your project? – olegst Apr 12 '17 at 9:03
  • 3
    From whom/where is the other person getting their tasks? Is it possible they've actually been assigned to rewrite the code? Is your own code covered by reviews and approvals? – jcm Apr 12 '17 at 9:09
  • 3
    Sounds like an architecture astronaut joelonsoftware.com/2008/05/01/architecture-astronauts-take-over I have worked with people that rewrite stuff with tons of abstraction in the past and it does not make for good code, it becomes too fragile and is very hard for other devs to understand. – NibblyPig Apr 12 '17 at 10:42
14

I don't think you need to do anything at all. But if I were in this situation, I would suggest a policy change that for any rewrites or redesigns, where possible the original author of the code should be consulted about the issue prior to work beginning and a mandatory reviewer of the finished code.

The normal rationale for this policy is that the original author will have a better understanding of the requirements the code has to meet and the design rationale behind it. But it also helps to prevent people from fixing things that aren't broken.

If you get a policy like this pushed through, you should be consulted before the next such "redesign". It is perfectly reasonable to reject such a thing by arguing that the benefits do not justify the costs and risks involved with changing code known to work.

But if this doesn't work, don't worry about it. If his manager thinks what he's doing is worth his time, then let him keep doing it. It is not your job to write perfect code but to efficiently write maintainable, documented code that meets the requirements and coding standards. If you can defend your claim that you're doing that, then let him do whatever he wants.

  • 14
    I disagree with your proposed policy. I support the concept of collective ownership of code. Since @eee is concerned about being held accountable, they could use code reviews instead; if anyone has objections, they better provide good arguments, and if the code is accepted, it isn't his business how other colleagues decide to waste their own time. – angarg12 Apr 12 '17 at 10:39
  • 1
    @angarg12 I support collective ownership of code as well. But I also support the policy of mandatory reviewers -- when you have a person who is especially familiar with a particular piece of code, it is silly to design, implement, and accept changes to it without consulting them. – David Schwartz Apr 12 '17 at 17:23
  • I think the answer should end at "You don't need to do anything at all." It's not his problem - it's his manager's. The proposed policy sounds like a terrible idea to me. You should never be so attached to your code that people NEED to run things past you in order to make changes. – Ethan The Brave Apr 13 '17 at 14:08
10

Rewriting other people's code is normal. It happens all the time; if the unit/integration tests continue to pass and it is getting code reviewed then just let it go.

But re-writing code that is not broken (it does what it is supposed to be done and is sufficiently efficient and its style is not affecting the development of other pieces of code) is not OK. This is a waste of time and resources.

The question now is how this waste of time and resources affects you. If you are the manager of the team then your teams productivity is being affected and that should bother you.

If this is a team mate then it does not affect you directly so its not worth bringing up. But it does affect the team as a whole and the ability of the team to execute on things may be affected and this could be brought up in a retrospective. But it should be brought up as not doing work on current priority tasks.

2

Separate out new features from code re-writing.

Make it clear that new or changed code should not have routines re-written just because the developer sees inefficiencies. Accept that you are the one who gives direction here. Give that direction and stick to it. When efficiencies are observed make sure that the impact on customers is identified. Sometimes this is in long term quality and infrastructure issues.

At the same time show that you care about quality code. Identify, and encourage that developer to identify these areas and for them to enter tickets for refactoring. Schedule a refactor week about once every 4-6 weeks and only do refactoring during that time.

The intent being to:

  • set priorities
  • encourage quality
  • relate development activities to the business goals

At the end of the day this is not a area that will have hard and fast rules. Sometimes a refactoring should be done right now as it is foundational work. Sometimes a refactoring should never be done as it will take a lot of work for little benefit to the business short or long term. The company makes money and pays salaries based on its priorities. It should be the one setting the priorities. I a developer wishes to base a company on different values they can work elsewhere, start their own business or try to persuade their current company. They have to persuade first though, not act first and persuade or justify afterwards.

1

The code becomes much more sophisticated after rewrites, with multiple layers of indirection and own "better" implementations of functionality provided by the standard libraries

I'm not 100% certain what you mean above - but could this be an opportunity for you to learn how to use the standard libraries in a better or more efficient way?

Is there a chance that his code is better and that the effort to rewrite your code is worth it? If so, I would hope that they would put you on the code review so you could learn to do it better.

Even if this guy is off base, he may not be completely off base - open your mind and look again, make sure you don't miss a learning opportunity.

  • I think what he means is that the new implementation bypasses the standard libraries which the original implementation had used. Sounds like a potential case of NIH – alroc Apr 12 '17 at 15:58
1

the coworker can always find developers closer to him for discussion and approvals.

This suggests that it's an oversimplification that there is a problem with the coworker. I would suggest that a better thing to change is how the team works together.

  • Perhaps some aspect of the review/approval process should be changed
  • Or the entire team should be trained on the dangers of overengineering
  • Training the team on prioritising work

One of the possible solutions would be to escalate to the management

Maybe you should, but with some suggested solutions about how the team can be trained to work better together and improve their skills and knowledge.

The training itself: I imagine you can google, but even (as it was in my previous company) as simple (and cheap!) as having weekly lunch sessions watching some YouTubed conference presentations, discussing them, seeing how what they said relates to your business/code base could be helpful. Or your colleagues could be encouraged to give presentations on some aspect of coding, accepting critical feedback etc. Maybe even reviewing coding books/blogs together, or academic papers. Or having group refactoring sessions. The team itself could probably suggest more!

I imagine encouraging a culture of honesty and self criticism would also be helpful. Tricky to achieve, but leading by example is often a good way to go! "Yes, my code here was a bit over-engineered here. How can we improve it?"

My suspicion is that seeing this more as an opportunity to push for more learning/training/cohesion for the entire team is far more productive (and cheaper/better for the business in the long run!) than trying to "deal with a problem employee".

0

This is primarily a problem of poor management.

If your team is conventionally managed, you and the other team members are assigned tasks. Either this other developer has been assigned to the task of rewriting your code or he hasn't.

If he has, it sounds as though your manager is allocating scarce resources to something that isn't advancing the project and is of little value to the company. If he hasn't, then the manager should be asking what's going on that requires gratuitous engagement in other developers' tasks. I suppose it's also possible that tasks simply aren't assigned on your team--but in that case it appears that the free-for-all isn't working out very well and should be re-examined.

If your team is attempting to use Agile principles and practices, well, it's not working. Two clearly stated Agile principles are:

Working software is the primary measure of progress.

and

Simplicity--the art of maximizing the amount of work not done--is essential.

If this is a Scrum team, your team is supposed to self-manage the allocation of stories within the sprint. The work that this teammate is rewriting: does it constitute a whole story? Is he "helping" you fulfill a story or is the story already completed when he starts on the rewrites? Does your team have a shared "definition of done"? And when you report at a daily standup meeting that you've completed a particular story, then your teammates are obligated to treat that story as done... or raise an objection. The entire point of having a daily standup is to deal with problems in the sprint quickly and directly.

Long story short, duplication of effort is the opposite of an Agile value, and your team needs to figure out how to stop doing it. Perhaps in your next sprint retrospective meeting.

There is also the possibility, which your analysis didn't address one way or the other, that your code interfaces closely enough with the other developers' work that he has at least some justification for making changes in the former to accommodate the latter. (Suppose you'd left it with some weird calling conventions or it didn't support some options that he feels are necessary.) Your team might need to work on making its specifications more clear or on communicating a little more before writing code.

One other thing I don't think anyone's mentioned yet: the cost here isn't just the other developer's time and effort. There's also the cost of sapping your motivation. You didn't say you're getting discouraged, but that would be a common and understandable reaction to having your work regularly erased and dismissed. People doing complex intellectual work don't do well at it if you keep making it irrelevant.

As I consider these possibilities though, they all come back to the team manager. That person needs to be aware of the extra time and effort going into duplicate work. Either they are aware, and are choosing to ignore the problem; or they're not aware, which suggests they're not following through on the tasks they've assigned to individuals, or they're allowing inflated estimates on the assigned tasks to serve as time buffers for those unassigned tasks.

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