I don’t think I’ll shock anyone by pointing out that you can find plenty of disagreements among software developers. Are singletons evil? Is TDD a good idea (or dead)? What’s the best IDE? You can see this dynamic writ large across the internet.
But you can also see it writ small among teammates in software groups. You’ve seen this before. Individuals or small camps form around certain competing ideas, like how best to lay out the unit test suite or whether or not to use a certain design pattern. In healthy groups, these disagreements take the form of friendly banter or good-natured ribbing. In less healthy groups, they create an us vs. them kind of dynamic and actual resentment.
I’ve experienced both flavors of this dynamic in my career. Having to make concessions about how you do things is never fun, but group work requires it. And so you live with the give-and-take of this in healthy groups. But in an unhealthy group, frustration mounts with no benefit of positive collaboration to mitigate it. This holds doubly true when one of the two sides has the decision-making authority or perhaps just writes a lot of the code and claims a form of squatter’s rights.
Status Quo Preservation
Division into camps can, of course, take many forms. But I think the one you see most commonly happens when you have a group of developers or architects who have laid the ground rules for the codebase and then a disparate group of relative newcomers that want to change the status quo.
I once coined a term for a certain archetype in the world of software development: the expert beginner. Expert beginners wind up in decision-making positions by default and then refuse to be swayed in the face of mounting evidence, third party opinions, or, well, really anything. They dig in and convince themselves that they’re right about all matters relating to the codebase, and they express no interest in hearing dissenting opinions. This commonly creates the toxic, adversarial dynamic here, and it leaves the rest of the group feeling helpless and frustrated.
Of course, this cuts the other way as well. Sometimes the longest tenured decision makers of the group earned their position for good reason and acquit themselves well in defense of their positions. Perhaps you shouldn’t adopt every passing fad and trend that comes along. And these folks might find it tiresome to relitigate past architectural decisions ad nauseum every time a new developer hires on. It probably doesn’t help when newbies throw around pejorative terms like “legacy code” and “the old way,” either.