{
Adam Ard
}
Strong Code Ownership
Martin Fowler describes the three categories of code ownership utilized in most software projects:
1. Strong code ownership breaks a code base up into modules (classes, functions, files) and assigns each module to one developer. Developers are only allowed to make changes to modules they own. If they need a change made to someone else’s module they need to talk to the module owner and get them to make the change. You can accelerate this process by writing a patch for the other module and sending that to the module owner.
2. Weak code ownership is similar in that modules are assigned to owners, but different in that developers are allowed to change modules owned by other people. Module owners are expected to take responsibility for the modules they own and keep an eye on changes made by other people. If you want to make a substantial change to someone else’s module it’s polite to talk it over with the module owner first.
3. Collective code ownership abandons any notion of individual ownership of modules. The code base is owned by the entire team and anyone may make changes anywhere. You can consider this as no code ownership, but it’s advocate prefer the emphasis on the notion of ownership by a team as opposed to an individual.¹
He continues to explain that, of the three, he only really dislikes strong code ownership and admits to a personal preference for “the dynamics of a collective code ownership”². Sadly, the agile community has largely followed suit with that opinion, and most companies now mandate that source code be modifiable by all. Such a policy comes at the expense of both quality and employee engagement. If you are aiming for a culture where engineers are both highly productive and take pride in their work, strong code ownership is your best option.
There are many compelling reasons to practice strong code ownership. I have written about some of them previously. In this essay, however, I want to visit the fascinating story of how China transformed itself economically by embracing the previously forbidden practice of ownership, or more specifically, the practice of 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 farm was located in the village of Xioagang where the people were struggling with a lack of food, resorting even to begging from other villages.
After realizing that something had to be done, secretly, they decided to parcel up their land among all the village families, allowing each to keep at least some of their own harvest, if it was bountiful enough.
They risked everything to try such an experiment as it was highly illegal, but in the end it was a great success. It netted a larger harvest “than in the previous 5 years combined”.
What was the difference? Just the rules of the game. In a word, ownership!
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.³
Where before:
There was no incentive to work hard — to go out to the fields early, to put in extra effort⁴
After the new arrangement, one could benefit from the fruits of their labor. They were the masters of their own fate.
Needless to say, it was not possible to hide their 5X increase in productivity from the government. But luckily, their actions where not viewed as treason but instead as instructional.
Among other reforms, China implemented the model of Xioagang’s partially privatized farm globally and “China’s economy started to grow like crazy. Since 1978, something like 500 million people have risen out of poverty in China.”⁵
What does ownership look like for software? How can you leverage the power of ownership to increase motivation and productivity in your organization? Obviously, developers don’t own their code in an absolute sense. When leaving a company, they can’t walk away with the code they wrote and use it somewhere else (unless it is open sourced). But they can own it in a way that gives the motivational benefits achieved but the Chinese Farmers of Xioagang. Parceling up the code base among coders makes everyone a custodian or steward over a piece of the application. They can be the guardian of its design, its test coverage, its coding standard. While taking pull requests, their detailed knowledge and emotional investment will make them rigorously attentive to what outside code can make it into their domain.
And what are the benefits that they reap from such efforts? The benefits are many:
- Mastery of a domain — If you don’t have a domain over which you have authority, this is impossible.
- Pride of good workmanship — You have something to look back at and be proud of that you were responsible for.
- Respect from peers — Other people have something to look at and appreciate that you were responsible for.
- Joy of knowing that you provided something of worth to others — it is easier to see how your work directly effected the customer.
- The increasing ease of sustainability and re-usability that only comes from constant attention to the state of a code base — If you can’t be the gatekeeper to the code, it is constantly changing in ways that are outside your control.
- A personal portfolio — you can build up concrete work examples that demonstrate your skills. From a management perspective, how else can anyone be accurately assessed for their contributions. (Given that software metrics have all proven to be marginally useful.)
All of these benefits are incompletely realized if not altogether lacking under a collectivist code ownership scheme.
Jeff Atwood makes a similar observation in his blog post, You Gotta Own It:
… 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.⁶
It is my belief that increasing employee engagement is the real secret to massive increases in productivity, more so than the latest process fad or flurry of team building activities. Strong code ownership is a pivotal part of securing that engagement.
Sources
3,4,5. https://www.npr.org/sections/money/2012/01/20/145360447/the-secret-document-that-transformed-china