Diffusing religious arguments

I called arguments between assemble-your-own vs. kitchen-sink framework approaches a religious one akin to tabs vs. spaces in my previous post. All of my leadership positions have been on brownfield products, usually turnarounds, so I’ve walked into minefields of religion that I’ve had to diffuse in order to focus on fixing the serious issues.

Some of the topics include multiple conflicting code styles in a single codebase; internal code styles that conflict with the official (or most popular) language coding styles; choice of a third-party library; strict vs. lenient linting and what to lint; and competing internal libraries or services that do the same thing. I’m not sure what type religious argument I haven’t run into, now that I think about it.

The process for resolving any of these is basically the same, but it requires quite a bit of you as a leader.

1. First thing first. If you are a manager who has a strong opinion on any of these, and you are ready to unilaterally decide because you think it’s the right opinion, don’t. Your job here isn’t to make a decision. Your job is to manage the process so no one cares about the eventual decision.
2. I have never come into a team having religious arguments that is healthy otherwise. Religious arguments are to me a symptom of underlying dysfunction. You must understand the underlying dysfunction. That usually includes poor code quality, little code reuse, poor reviews, or inadequate automated testing. Usually there are also other process and management issues. After all, bad codebases aren’t created in a vacuum.
3. Passion people bring to religious arguments can be rerouted into more constructive pursuits. Often the passion is around the religious arguments because that’s all they feel empowered to have an opinion about. Now that you understand the dysfunction, come up with a direction that fixes the dysfunction. For me, this has generally been introducing automated testing. The only way to ultimately diffuse religious passion is to make everyone feel like they are making an impact with their work. Show them what’s important, and help them channel the passion in that direction.
4. Now that a foundation is established, we can start on the precise religious argument. Understand both sides of the issue to the point that you can debate equally well from either side, no matter what you personally believe. This is necessary so that you can gain the trust of both sides.
5. Take your own opinion completely out of it, and decide which is better for your chosen direction. Usually this means standardizing on what’s already there with a level of consistency that’s appropriate for the codebase and programmers. You may find this choice is different from your personal opinion.
6. Discuss the topic individually with folks who disagree with the decision you’re planning. Your goal is to make them see the bigger picture, not convince them to change their religion. This is very much in the realm of how to win friends and influence people. You need to demonstrate you understand their position, maybe acknowledge that they even have the more rational position. If you can get them on board with the larger goal, their active objection will fade away.
7. Get consent and make sure everyone feels heard. Avoid steamrolling, even when dealing with a small minority. Anyone who doesn’t feel heard this time is unlikely to speak up next time. Your goal, again, is not to get everyone to agree, but to make the people who disagree still be vital to the success of the team. This also doesn’t mean to never discuss the topic again, but I have found it does change the tenor to be clearly academic, with little emotional investment, and (hopefully) only involving the people that enjoy that type of debate.

Fortunately, this gets easier each time you do it. When I arrived at CCP Games, each team on the EVE project had their own casing, conventions, unwritten style guide, and wrapper libraries due to years of broken promises between teams. You would not be surprised to learn that there was zero unit testing at the company. Adding unit testing and strong code review was what I poured my energy into, and as it got results, other teams got on board. Teams stopped reinventing wrapper libraries when they could find a library from another team they could actually use (because it was collaboratively designed and built) and trust (because it had tests). They would actually read and maintain other teams’ code, because they no longer were in an adversarial situation. I still remember when we decided to adopt PEP8 as our official coding style. There was no controversy or argument, because we understood how little it mattered to the larger goals we had around software quality.

At Cozy, the situation was very different but we still had many areas to religiously disagree. They never could really came to a head, though, because the codebase was in really good shape (after we replaced the most horrifically built product I’d ever experienced). Our Ruby style for instance: I hate spaces inside parentheses, yet I loved our use of tabs. But what sort of monster would abuse their authority to create an equally arbitrary standard? Likewise, imposing a community standard would have resulted in no improvement in software quality or velocity. Our religion was what it was, and we were going to focus our effort on the areas that mattered.