Sharing is the Root of all Contention
On Ending Collective Code Ownership
So I was looking at one of many e-mails from programming recruiters, and due to its relation to C++ game development, I took an interest.
I’m rarely willing to respond to these recruiters because everywhere I go, I keep running into the same organizationally-imposed engineering problem. I’m not yet desperate enough for cash to take the bait, but I ultimately responded to the e-mail because I wanted to use the dialogue as an opportunity to articulate my recent understanding of this problem.
Over the past few days, I have come to understand that the most pernicious difficulties engineers face have one primarily cause — unnecessary organizationally-imposed contention.
I will try to explain.
In modern corporate ideology, the more ownership and responsibility is shared, the better things are supposed to be. But as Herb Sutter wryly pointed out, sharing is the root of all contention. Of course, Herb was talking merely about the hazardous technical aspects of sharing state among concurrent processes… but I think the wisdom in his statement may echo much further than he may have intended.
Undemocratic socialism — that is, the kind of authoritarian socialism you find in corporations that follow this lazy share-everything ideology, doesn’t have positive effects. For those of you who have lived in these miniature dystopias for any length of time, you know it breeds dead-locks, bickering, politics, resentment, misery, project risk, and turnover — while at the same time minimizing team output by at least an order of magnitude.
So being the hopeless fool that I am, I decided to respond to the solicitation above with a suggested approach that would drive a stake in the heart of this nonsense as deeply as one man can, at least in his own corner of the engineering world. Here is the full text of the e-mail -
I find this type of position interesting as a lead engineer.
However, I am looking for some specific organizational capabilities for this position. I have found needless contention to be at the root of most engineering and organizational problems, so I strongly advocate an organizational approach that minimizes it. Here is an outline of the 5 disciplines that I advocate to minimize engineering and organizational contention among engineers -
1) Do not adhere to collective code ownership, but rather delegate ownership of individual code modules according to engineer’s interest, expertise, and availability. If the scope of the delegated module grows, the owning engineer may in turn delegate sub-modules to other engineers as needed. Delegated code ownership minimizes engineering contention by removing unnecessary sharing of code and disambiguating engineering responsibilities.
2) I adhere to a modular approach to C++ programming that I would ask the team follow — https://github.com/bryanedds/das [EDIT: this is how you achieve the same type of modularity in F#]. This approach minimizes engineering contention by allowing engineers to collaborate mostly only at the boundaries of their code’s contracts rather than inside implementation details. In practice, object-orientation does not achieve this, but rather ends up exploding engineering contention instead.
3) I require the team members to test their own code via interfaces they provide to the rest of the team according to the level of abstraction — from unit tests at the bottom, to integration tests in the middle, to smoke and compliance tests at the top.
4) I strongly advocate for closed, private spaces for each engineer, as that reduces unnecessary social contention. If an engineer is not happy where they are placed, they can be relocated somewhere more desirable to them, thus reducing cultural contention.
5) I ask team members to understand the advantages of minimized engineering and organizational contention, and ask them to bring other problems caused by needless contention to my attention.
If this approach is acceptable in the context of this position, I am very excited to talk further about it!
Now, who wants to bet that any of that will fly? Anyone? Anyone at all?
I wouldn’t. And the reason I wouldn’t is because the ideology of undemocratic socialism is so deeply embedded in corporate America, that I’d be lucky if my response were considered anything other than a joke.
But this is no joke. The disastrous consequences of the American corporate ideology underlies pretty much all the misery engineers experience on a daily basis - the fubar’d code bases that antagonize us endlessly, the broken software that is shoveled out to the consuming public, and the skyrocketing costs of development.
When I don’t get a response, I’ll move on just as if I never wrote the e-mail. But maybe this medium article will have some impact, and get some engineers thinking that maybe, just maybe, we’ve been moving in some wrong directions for the past 20 years.
At any rate, here’s more cute cuddlies ‘sharing’ together :)
“At least one of the reasons for collective code ownership i understood was to reduce risk wrt losing team members. I always thought it increased enjoyment of people working on it, because it people got to work on different domains. The notion of staying in one area seems like you’d loose these good things.
“I’ve worked in cube farms, separate offices, and the current “pod” environments. I’m very much in favor of the current pod model (teams work in open rooms, with lots of separate spaces people can go to work alone if they prefer that). Doesn’t the ability to choose which works for you seem superior to everyone in offices?”
I took the opportunity to reply with additional detail:
“I didn’t go into full detail, but in order to reduce the bus factor, in addition to each module having an owner, you also have a code steward. In addition to having the steward help the owner review the code, it’s also the steward’s responsibility to pitch in where the owner needs some temporary help, be the first to be delegated any newly hatched sub-module, or even be able to replace the owner should he, well, get hit by a bus.
“If a person enjoys working in multiple domains, there’s nothing keep them from getting ownership over various modules. But not all engineers can or should be treated like plug-compatible components.
“If certain individuals would prefer to work in a more open environment, that should be their option. But again, that’s not how everyone works best, so forcing an open environment on everyone is a bad practice due to the social contention it creates among those who don’t like it, in my experience.
“Minimizing contention in the work place does have trade-offs, of course, but on balance, I think it’s an order of magnitude better than the contention-maximizing models that most companies have in place. To the point where I simply won’t work for those types of companies.”
Thanks deeply, Karl, for the fruitful discussion!
“I’ve seen the code-owners model degenerate into chaos and conflict more often than collective code ownership.
“Well, the ultimate answer is that there’s no silver bullet and different things work for different people, but some specific problems with code-owners revolve around the fact that some modules are more prestigious than others, there is competition to own certain modules. Also, it’s quite common for a change to cross modules, unless by some miracle your team structure matches every eventuality perfectly; in this case the implementation can differ massively depending on which owner is the primary owner of the change, they will prioritise their own needs first. In passive-aggressive cultures (it happens) this can break-down massively, Person A wanting to retain ownership of component X making changes in such a way that Person B owning component Z has to constantly react to, falling behind the component Z schedule.
“TLDR — collective code-ownership involves a lot of contention, but code ownership is massively political.”
“My experience is that collective code ownership falls into chaos 100% of the time, and that the conflict which would otherwise happen at the boundaries of modules instead moves upward into the organization. Which is probably the worst thing you can do.
“What you end up with is a code base of near-zero quality because no one is long vested in taking care of any of it, a bunch of disenfranchised engineers being treated like interchangable code monkeys, systematic brain drain of your best engineers because no one has any pride of ownership, software architects who act more like politicians than engineers since they know none of the invariants they implements will go unmangled, turnover that rivals that of a fast-food chain, and product releases that are of low to middling quality.
“With code ownership, there is still going to be some conflict, but it’s contained explicitly, minimized, and doesn’t escalate up to the organizational level.
“And in your case, if the team lead see malicious acts like those undertaken by your Person A, then Person A can be moved to a less important module, and if continues to act maliciously, ultimately removed from the organization.
“Humans are often political, the best you can do is make it explicit where it’s unavoidable and work to minimize it. I would venture to guess that you saw more politics in ownership not because there is more, but because it is less hidden than in collectivization. Like bad code, politics is best made explicit such than it can perhaps be dealt with directly. In collective code ownership, it is so hidden that there is no hope to address it.
“In my analysis, reducing engineering and organizational contention is the best possible way to minimize politics. If there were a way to get rid of politics entirely in software engineering, I would advocate that.
“TLDR — there’s not less politics in collective code ownership, it’s just that it’s more indirect. Code ownership makes it more explicit, thus allowing it to be addressed directly.”