# Experience Report: Weak Code Ownership

DevFeed: [Experience Report: Weak Code Ownership](<https://devfeed.tech/articles/experience-report-weak-code-ownership-31915.md>)

Original publisher: [Read original article](<http://blog.jayfields.com/2015/02/experience-report-weak-code-ownership.html>)

Author: Jay (noreply@blogger.com)

Published: 2015-02-23T15:00:00Z

Content type: opinion

Language: en

Sources: [Jay Fields](<https://devfeed.tech/sources/jay-fields.md>)

Topics: [Code](<https://devfeed.tech/topics/code.md>), [Software](<https://devfeed.tech/topics/software.md>), [optimize](<https://devfeed.tech/topics/optimize.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [collective](<https://devfeed.tech/tags/collective.md>), [developers](<https://devfeed.tech/tags/developers.md>), [experience-report](<https://devfeed.tech/tags/experience-report.md>), [opinions](<https://devfeed.tech/tags/opinions.md>), [optimize](<https://devfeed.tech/tags/optimize.md>), [team](<https://devfeed.tech/tags/team.md>)

## AI overview

The author reflects on moving from Collective Code Ownership to advocating Weak Code Ownership after experiencing disagreement and reduced productivity on a team of senior developers. The article argues that talented developers often work in incompatible ways, making it difficult to optimize a shared process for everyone.

## Source excerpt

In 2006 Martin Fowler wrote about Code Ownership. It's a quick read, I'd recommend checking it out if you've never seen it. At the time I was working at ThoughtWorks; I remember thinking "Clearly Strong makes no sense and I have no idea what scenario would make Weak reasonable". 8 years later, I find myself advocating for Weak Code Ownership within my team. Collective Code Ownership (CCO) served me well between 2005 and 2009. Given the make-up of the teams that I was a part of I found it to be the most effective way to deliver software. Around 2009 I joined a team that eventually grew to around 9 people, all very senior developers. The team practiced Collective Code Ownership. Everyone on the team was very talented, but that didn't translate to constant agreement. In fact, we disagreed far more often than I thought we should. That experience drove me to write about the importance of Compatible Opinions. I still believe in the importance of compatible opinions, but I now wonder if the team wouldn't have been more effective (despite incompatible opinions) if we had adopted Weak Code Ownership. The 2009 project heavily shaped my approach to developing software. I suspect I'm not the only one who (at one time) believed: if we get a team full of massively talented people we can do anything. It turns out, it's not nearly that easy. Too many cooks in the kitchen is the obvious concern, and it does come up. However, the much larger problem is that talented people work in vastly different ways. Some meticulously refactor in small steps, others make wide reaching and large changes. Some prefer one language to rule them all, others are comfortable switching between 12-15 different languages in the same day. Monolithic vs separated codebases. Inherited vs duplicated config. It goes on and on. You try to optimize for everyone, to ensure everyone is maximally effective. Pretty quickly you run into this situation- If you optimize everything, you will always be unhappy. --Donald Kn