Code Stewardship

2018 Aug 19 - David Cox

I've heard "Code Ownership" referred to quite a bit in my career, but never actually talked about it - not directly, at least not any way pertinent to my employment.

Pretty early on I decided Code Ownership was a myth. What sensible, competitive, profit-motivated business would grant ownership of their code base - indeed, their very product - to their engineering team?! No, the concept of Code Ownership must be just another one of the recruiting platitudes used to entice Millennial developers.

I've recently come to understand the concept of Code Ownership in a new light.

Code Ownership doesn't have anything to do with actual ownership of code. It's more about responsibility and the understanding that the designated "owner" is going to look after the code's well-being (it's readable, testable, performant, useful, and complete). The business organization actually owns the code. The engineer is its caretaker.

In this light, I suggest referring to this faux "Code Ownership" as Code Stewardship.

Code Ownership vs Code Stewardship

Code Ownership certainly has a nice ring to it. It sounds absolute, concrete, and powerful. The reality is far from that. The demands of the business dictate what features of the product need attention, and by extension, when the existing code need to be transformed to meet those needs. The "Code Owner" engineer may dictate the specifics of how the code will be changed, but can only offer suggestions regarding when, why, and to what end.

Code Stewardship lacks the bravado of Code Ownership, but is more accurate and direct about the relationship between the engineer and the code. The engineer will do his/her best to maintain and improve the code but understands that ultimate authority over the code rests elsewhere. The engineer may share stewardship with one or more others, and the time may come when the engineer will need to give up stewardship.

This may not seem like much, but the way we speak about things has the ability to influence the way we think about things.

If an engineering organization espouses Code Ownership in their recruitment and motivational practices, how will the engineers take it when their proposals are passed over, their deadlines are shortened, or their projects are reprioritized?

If that same engineering organization has instead invested time evangelizing Code Stewardship, how might the reactions of their engineers be different when faced with the same circumstances?


I suspect most engineers and managers know what each other mean when they talk about Code Ownership. No one expects to walk out the door in possession of the company's source code - at least not without being very secretive about it.

Be that as it may, employer and employee still owe it to one another to represent their intentions plainly and honestly. If an organization is marketed to recruits with hyperbole and vague assertions, it can't be too put-off if, even years later, those recruits don't like what they find when they see past the smoke and mirrors.