Strong Code Ownership
Lessons from Xiaogang
Martin Fowler describes three categories of code ownership:1
Strong Code Ownership: Each module (classes, functions, files) is assigned to one developer, who exclusively makes changes. Others must request changes through the owner, often by submitting patches (or pull requests).
Weak Code Ownership: Modules have owners, but anyone can modify them. Owners monitor changes to their modules and collaborate on significant edits.
Collective Code Ownership: The team owns the codebase collectively, allowing anyone to make changes anywhere. Advocates emphasize team ownership over individual control.
Later in his article he says, “Of the three the one I really don't like is strong code ownership” and admits a preference for “the dynamics of a collective code ownership team—particularly in the context of Extreme Programming.” The agile community has followed suit with that opinion. On most teams, anyone can edit anything.
As Fowler points out, this model works well if you use the collaboration practices from Extreme Programming (XP). But I believe the industry was too hasty to dismiss strong code ownership, which provides its own set of benefits2 (especially when run like an open source project). It can be just as effective as XP and sometimes, when considering the individual preferences and talents on your team, it may be the better option.3
Ownership in Xiaogang
Consider the story of how China transformed itself economically by embracing the previously forbidden practice of ownership—allowing workers to reap the direct benefits of their labor.
In the 70’s, in China, there was no concept of private property. Farmers worked on collectives where the government took all that was produced and divided it equally among all families. One such collective was located in the village of Xiaogang where residents were struggling to grow enough food, resorting to begging.
Realizing that something had to change, secretly, farmers in Xiaogang parceled up the land among the village families, allowing each to keep at least some of their own harvest, if it was bountiful enough. They risked death to try their illegal experiment, but in the end it was successful. It netted a larger harvest “than in the previous 5 years combined.”4
What was the difference? The rules of the game. In a word: ownership. Where before:
There was no incentive to work hard — to go out to the fields early, to put in extra effort5
Now the village was motivated. It thrived. After the secret arrangement, villagers became masters of their own fate.
It was the same land, the same tools and the same people. Yet just by changing the economic rules — by saying, you get to keep some of what you grow — everything changed.6
Needless to say, it was not possible to hide a 5X productivity increase from the government. But luckily, their actions where not viewed as treason but instead as instructional. Among other reforms, China implemented the model of Xiaogang’s partially privatized farm nationwide and “China’s economy started to grow like crazy. Since 1978, something like 500 million people have risen out of poverty in China.”7
Ownership in Software Development
Software teams can reap the same benefits of ownership as Xaiogang. Obviously, developers don’t own their code in a legal sense; when they leave the company, they don’t take source code with them and use it elsewhere. But they can still own the code in ways that yield the motivational benefits achieved by the Chinese Farmers of Xiaogang. Parceling up the codebase among team members, in a strong code ownership arrangement, makes everyone a custodian or steward over a piece of the product. Individual programmers can be guardians of their piece’s design, testing, and quality. When evaluating pull requests, their detailed knowledge and investment make them rigorously attentive. All code must conform to their personal standards to be acceptable.
There are many benefits of strong code ownership; below are a few:
Mastery of a domain : Focus on a narrower section of code makes it easier to master.
Pride in workmanship : It’s easier to look back and be proud of good results in your stewardship—the code over which you were solely responsible.
Respect from peers : It’s easier for others to appreciate good results in your stewardship.
Joy of providing customer value : It’s easier to see how your work directly effects the customer, as they interact with the code from your stewardship.
Code cleanliness: With gatekeepers, code changes are rigorously vetted and stay true to original design.
Personal portfolio : It’s easier to collect concrete examples of your work and easier for your manager to assess them.
Higher quality: Programmers tend to take better care of their individual stewardship, better than code shared by everyone. In a 2011 study examining the relationship between code ownership and software quality, Microsoft determined that files with clear ownership had fewer defects.
The Pendulum Always Swings Too Far
Before the agile revolution, strong code ownership was common. Jeff Atwood’s article from 2005, You Gotta Own It, displays a strong code ownership ethos:
… Renters don't take pride in their homes. Only homeowners do.
… if you do want great software, you have to let the developers own what they’re building. The developers are inevitably the ones who have the most control over the success or failure of the project. Creating an environment where your developers have no emotional attachment to the project they’re working on is a recipe for mediocre software — and job disillusionment.
The notion of "egoless programming" is dangerous and wrongheaded.
…Smart organizations cultivate this sense of ego-driven ownership with an implied trust: they go out of their way to hire smart people, and then they get out of the way.
If you're not working in an environment where ownership is encouraged, either wrest control from the powers that be, or start looking for another job. You gotta own it.8
He quotes Joel Spolsky:
Software, by its nature, is very easy to divide into smaller and smaller components, so it's always possible to divide up responsibility among people and let people own an area. This is probably THE reason why software people love working at Microsoft.9
A lot of good software was built with strong code ownership. We know it works.
But with agile’s rightful rejection of waterfall’s upfront planning, a shift towards shared code ownership came along for the ride. While it did popularize a collaboration model ideal for extroverted programmers—that were perhaps suffering from feelings of isolation—the pendulum swung too far the other way and cut out the introverts—programmers that draw energy from being alone. After agile came, the suffering switched to them.
It doesn’t have to be one or the other. Strong and collective code ownership teams can co-exist in the same organization and service both personality types. (I don’t think it’s a good idea to do both on the same team though) Neither type need be overlooked. Programmers may even benefit from trying out “the other side” once in a while depending on the circumstances.
So, for the sake of suffering introverted programmers everywhere, please don’t discount strong code ownership. It can be just as effective as a well run XP project and, for some teams, it may be superior. On your next project, especially if your team needs a motivational boost, give strong code ownership a try. It may just be the change you need.
Scrum implementations tend to be stuck somewhere in the ineffective middle of these two options, reaping the benefits of neither one.
https://www.joelonsoftware.com/2000/03/19/two-stories/
Yep, I'm more of a strong code ownership person too. I miss the days where I could focus on something until it was really clean and maintainable.
Me being more on the extrovert side, I would say that strong ownership is great. I know there is code running in a company that I wrote 5 years ago. It was my code, I worked hard to implement that functionality during some months and I took it personal, like my own thing.
I remember that, once it was working as expected, I took some small time before release to refactor it and leave the code in a very understandable state, the logic was clear and easy to modify. Some year later I had to add some extra things. It took me 5 minutes, because I knew it at heart.
Recently, I was told they didn't need to touch it or modify it much: I designed it to be capable of take some extra related functionalities that, at the time, were not relevant.
Giving back that personal pride to developers is, in my opinion, something we need to do. That will help in creating better software... and better developers.