How does one deal with backdoor code changes?

Question

Scenario

I admit (somewhat shamefully) that I have not only witnessed this particular practise, but I have also committed it myself. My name is Jeff and I have gamed a quality process to get my way. The scenario I am referring to is this.

Engineer A wants to do something a certain way but Engineer B has already implemented it. Rather than work within the framework defined by Engineer B's implementation, Engineer A rewrites it to match their own way and then finds a suitably weak reviewer (or some other kink the process) to ensure their changes get through.

This of course has a knock on effect where Engineer B discovers the subterfuge and proceeds to find a way of getting their original approach re-instated by similarly nefarious means, and thus the conflict begins.

Solutions

There are many potential solutions to this scenario, such as having a single person responsible for assigning reviewers or pair programming, but I'm not sure these can really stop the determined engineer. I also don't think that not hiring engineers likely to do this is the best plan because quite often it is those engineers with the best abilities that tend toward this dismissive behaviour of "my solution is clearly better than theirs".

This is generally a side-effect in agile processes where the detailed design phase is blurred with implementation such that the review is also the design sign-off. This is obviously a major area where the problem could be also addressed.

Question

What approaches to a quality process mitigate this? Do you have any experiences to recount that shed light on what to do or what not to do? What were the consequences (good, bad, nonexistent)?

I should add that I am asking as we are trying to combat this issue in our own project - hence asking here.

Answer 1

1) A strong coding standards document that also includes code patterns.

2) A team that discusses things together to agree on a common way forward instead of implementing passive aggression against their coworkers.

3) A team that is willing to listen to other people, instead of each member thinking their own way is best.

4) Deferring to seniority within a team once a decision is made. This is hard if the senior member doesn't personally implement (3).

Answer 2

I haven't seen any positive correlation between good engineers and antisocial behaviour like that. Most really good programmers and architects I've met were good communicators who got their skills by learning from other people. Programming is a team effort. Someone like that needs to be very productive to compensate for the negative impact they have on the other programmers

I don't think that this is a side effect of agile. I can see this happen in failed agile implementations but in my experience agile teams are better at working together and are more aware of what everyone is doing. Short iterations and fast feedback on team performance usually makes counter productive behaviour like this very visible.

The key to solving problems like this is communication. People in a team need to be aware of what other people in the team are doing to be able to function as a team.

Keep to a reasonable team size. Large teams cause communication difficulties. Split up teams that are too large into smaller teams that have their own responsibilities.

Have daily stand up meetings where people share what they did yesterday, what they plan on doing today and what problems they have. This can prevent people from implementing design changes in secret.

Make sure people are colocated. Having people sit together and work together makes them more inclined to seek solutions together.

Of course problems like this can occur but if this happens often it can be an indicator of other problems within a team.

Answer 3

I've seen this behavior in a few scenarios:

1. Engineer B left a mess and Engineer A is cleaning it up.

2. Engineer A thinks Engineer B left a mess and she is cleaning it up.

3. Engineer A isn't strong enough to read and understand the existing solution so he rewrites it in a way that makes sense to him. Reading code and understanding it is harder than writing code.

4. The team isn't focused on a "leave no trace" approach to development - touch as few classes, methods, and control structures as possible to fix a bug or tweak a feature, because every change has a potential side effect. Engineers are allowed too much room to noodle.

You solve each scenario differently:

1. Are all engineers constantly rewriting one person's code? Watch closely and determine if Engineer A is struggling. Maybe she's not keeping up. Maybe she's creating problems. If so, work with her to get up to speed. If that fails, she has to leave for the benefit of the team.

2. This is the ego issue you mentioned in JeeBee's comments. The other answers here give good suggestions for reducing the problem. If ego problems persist, I'd say the team has the wrong focus. The point should be to get as much done in the least amount of time with the fewest bugs as possible. Constantly rewriting another engineer's code isn't contributing to that effort.

   Encourage the team to answer these questions before they make a change: Is my solution really that much better? Do I really understand what the other engineer was trying to do or am I just being lazy and rewriting it in a way that makes sense to me? If it's objectively better, why do I know that Engineer B is going to come right back in here and change it?

3. Is one engineer constantly rewriting everyone's code? Watch closely and determine if he's struggling. If so, work with him to get up to speed. If that fails, he has to leave for the benefit of the team.

4. I've been blessed to work with great teams, so in my experience, this is the most common problem. We solved it by first admitting we had a problem (maybe I'll develop a twelve step program for noodlers). Great engineers/developers are noodlers. They tear things apart and put them back together. Their first instinct, even when revisiting their own code, is to tear it apart and make it better. This is great during the design and discovery phase but is dangerous later in the dev cycle. So, admit that you're a noodler. Each time you pull the latest from source control, resist your noodling instinct. Ask yourself what's the least you can do to solve a problem. Get everyone on the team to commit to a "leave no trace" dev approach.

   Don't shut down your inner noodler for good, though. If you find it increasingly hard to resist your noodle-urge in a particular part of the app, it might be time for major refactoring. Come up with a plan and present it to the group. If it's a truly good idea, they'll likely agree.

Answer 4

One approach I've seen is to appoint 'Guardians' - fairly senior developers, each of whom is responsible for the ultimate state of one particular module of functionality.

In case of an implementation dispute, the final word goes to the module Guardian.

Often the Guardian role extends to more involved work like architecture, quality control and so on.