Code Ownership, Stewardship, or Free-for-all?


(3 comments)
February 16th 2022


As the pendulum has swung from monoliths to micro-everythings - services, front-ends, you name it - we find ourselves with more "things" to build and maintain. And so it begs the question, who is responsible for what?

As a simple example, imagine a small team of, say, 6 developers:

The team has created and now supports a mobile app, an Alexa skill, three separate web apps, fifteen microservices, and a partridge in a pear tree.

And while they've managed to enforce some level of standardization across the ecosystem, by the very nature of modern software development, it's just a lot. There's Python, Django, DynamoDB, S3, React, Typescript, Tailwind, Swift, and much more, all working together to implement user interfaces, APIs, data persistence, integrations, and so on.

Too much for any one developer.

Moreover, each sprint comes with different demands for enhancements and fixes, and the work is rarely distributed equally across the codebases. One sprint might require heavy changes in the mobile app, and the next might need mostly back-end work.

So again, the question is: how is a team best deployed to fulfill the demands of the business, sprint-after-sprint? In other words, how do we best divvy up responsibilities?

For example, do we encourage specialization - say, assign Emily to handle all the mobile development, let Joe own the web components, and so on? And beyond just tech stack, if we have over a dozen microservices, do we draw some boundary around them, and say Javier owns microservices A and B, Anna C and D, and so on? But what happens when work in their specific area is light for a few sprints in a row? Are we comfortable with them having a little idle time?

Or do we try to better optimize utilization, and encourage a more full-stack, cross-domain culture? Each developer does it all! But wait...is this reasonable?

Drivers

Just like when building software, before we jump to a solution we should step back try to figure out what we're trying to solve. I'd argue, there are four big things to consider when thinking about developer responsibilities and ownership:

  1. The obvious thing is productivity. All things being equal, we would like to structure the team in a way that maximizes the work they get done. I mean, this is why we're paid! And so optimizing productivity typically means keeping some consistency for developers, aligning their work with their skill-sets and experience. For example, if Emily worked on the mobile app last sprint, she should be able to knock out that next feature faster than, say, the developer who has been working in the backend.
  2. We also want to be mindful of quality. And similar to above, it's likely that the developer with more hands-on experience in a given codebase will also implement the next feature with higher quality than the one who was parachuted in for one sprint only and doesn't know the structure, patterns, or conventions. Even the best developers can write crappy code when they don't understand the codebase.
  3. Here's where it gets tricky though. The organization often also needs to mitigate the risk of a developer leaving, and with it their knowledge. And this often runs counter to the goals above. Whereas assigning one single mobile developer to all the mobile development sprint after sprint might maximize both productivity and quality, it puts the organization in a precarious position when that developer starts getting texts from the Meta recruiter.
  4. Finally, we can't ignore the less-tangible dimension of developer happiness. But this too is complicated. Some of us like variety and newness, and so if we're stuck with the same system sprint after sprint, it could affect our productivity or make us more likely to jump ship. Others prefer predictability and take pride in having their own turf. Bouncing around would drive them crazy. In other words, each of us is different, but ensuring that we're fulfilled and challenged is important.

Now assuming these are the right factors to consider, the crux then is that every organization has to choose its "weights" for each. What's most important to optimize? Maybe there's some time-critical force (deadline) at play, and productivity needs to be optimized above all else. Or maybe the market for developers is so hot that the most important thing is just keeping developer happy, productivity be damned! In other words, it's very much context-dependent.

Hand waving over the "how" here, and assuming the organization knows what it's trying to optimize, it needs to pick some model for structuring responsibilities for the team. But what are the options? Here are a few of the popular models I've come across:

Ownership

Often, we settle on a strategy of code ownership. Sometimes it's tacit - everyone just respects that Joe usually does the web stuff, Emily does mobile development, I do the payment microservices, and so on. Other times it's formalized - management hired Joe as The Web Developer, Emily as The Mobile Developer, and so on. In either case, in practice it plays out similarly. When new features or fixes come in, we divvy it all up according to what we "own". This allows us to be maximally productive (in an individual sense), and also increases quality (usually). There are a few downsides however.

First knowledge of different systems can be hoarded, representing a huge risk if someone "wins the lottery"/"gets hit by a bus", as they say. Additionally, "ownership" can sometimes feel like a shackle to developers, if what they want to be doing is learning new things. Lastly, it must be noted that while individual productivity increases (since the developer knows their codebases well), collective productivity often decreases with ownership. As discussed above, because work loads don't cleanly balance out each sprint, this can lead to a feast and famine situation for the owning developers. For example, one sprint there's more work in their codebase than the owner can handle causing big bottlenecks (or late nights!), and the next month there's not much to do, and that owner is more or less idle.

Free-for-all

When an organization feels some of these pains of ownership, they often abandon any strategy at all and just wing it: i.e free-for-all. This system is as simple as it sounds. A manager sees a pile of work over there, and says "hey you, code-person, get after it!" And that's that.

While this strategy does ensure that we balance our overall allocations (i.e. Emily the mobile developer isn't idle when there's no mobile work, because she gets pulled over to work on the Python service), this model can be both exhausting and fraught with quality issues. If we don't have any long-lasting connection to the codebase we're working in, our work is guided only by expedience and ignorance. We shoe-horn a janky short-term fix in because either we didn't know any better, or because we don't really care much - we'll be in a different codebase next sprint! As they say, "no one has ever washed a rental car".

The free-for-all model is often driven by management who idealistically sees us as interchangeable handymen (i.e. the mythical Full Stack Developer) - quickly able to tackle with grace and ease any technical challenge, no matter what tier, system, or business domain. And of course this is bull-shit. For all but the most trivial systems or all but the most exceptional developer, there is too much complexity to be able to navigate our way through everything without proper time to ramp-up.

Stewardship

Now somewhere in between these two extremes of ownership and free-for-all is a model of stewardship (or custodianship). Similar to ownership, developers look after certain codebases where they have the most expertise - they probably did most of the initial work in the project, and their name is all over the code, but they're not responsible for doing everything. At the least though they must be consulted on changes and be pulled in to triage production issues or discuss design changes.

This allows for, say, Emily to go over and jump in and give Joe a hand with the web portal when the workload there is high, but to return to her mobile app when things die down. In other words, it balances both individual and collective productivity. Additionally, this model also can balance nicely risk mitigation and developer happiness, as developers build some level of familiarity with other pieces beyond their own (i.e. get to learn new things).

The important thing with stewardship is that, while it's less formal that ownership, it is still explicitly defined and held to. At a minimum, a few things should be in place. There should be a list that defines who is steward of what, GitHub (or whatever SCM tool) should be configured so that stewards must approve all pull requests, and stewards should be given enough allocation (time) to do the necessary "stewarding" of their component. Unless there's some formality and discipline around this, everything will just slide down the slippery slope until you find yourself in the pit of the free-for-all.

Conservatorship

Lastly, it's probably important to also recognize a model that's very popular in bigger organizations, and that's what I'll call conservatorship. This is the idea that there is a chosen few (usually astronaut architects) who have the responsibility of "owning" everything. They hold the knowledge, make the important technical decisions, and design the business logic/structure, but the actual down-and-dirty work is done by whichever developer is available, usually in free-for-all type of way.

In theory, this model works great. Efficiency and quality are optimized by virtue of conservators sharing their "wisdom" with the hands-on developers, thereby clearing the path to the quick and effective solution. And with the help of the conservators, developers can just swap in and out of codebases, relying on the conservator to get them up to speed quickly. That's the idea at least.

In practice, it never works out like this. Conservators, without any hands-on experience, quickly become detached from the on-the-ground technical reality, and often are no real help at all to developers who need to implement some enhancement or fix some defect. It can take a developer just as long to ramp up, and additionally can be frustrating because they basically cede their autonomy (and creativity) to the conservator who gets to call the shots.

Speaking as someone who has played this conservator role, I can attest to how little help I was to the hands-on developer who needed to get real work done within the systems I supposedly "owned". This model, in my opinion, sucks for everyone - and this is why I try to avoid these types of roles.

In Summary

In the end, what started in my head as quick post about different models of code ownership went way longer than expected. This is how I think about it though, and these are just a few models I've come across for divvying up work. I'd love to hear your thoughts and experiences.

* And yes, if you were wondering, I thought of the name "Conservatorship" after watching the Free Britney documentary with my wife. :)

I'm an "old" programmer who has been blogging for almost 20 years now. In 2017, I started Highline Solutions, a consulting company that helps with software architecture and full-stack development. I have two degrees from Carnegie Mellon University, one practical (Information and Decision Systems) and one not so much (Philosophy - thesis here). Pittsburgh, PA is my home where I live with my wife and 3 energetic boys.
I recently released a web app called TechRez, a "better resume for tech". The idea is that instead of sending out the same-old static PDF resume that's jam packed with buzz words and spans multiple pages, you can create a TechRez, which is modern, visual, and interactive. Try it out for free!
Got a Comment?
Comments (3)
Johnny Golden
February 18, 2022
Great stuff as always!

The biggest challenge I've run into is how to assign projects across the spectrum of seniority.

Maximizing productivity is a short-term concern, and is accomplished by seniors building everything. One downside is that seniors can quickly become stretched in so many directions that they're much less productive. Whenever they try to sit down and focus on something, a production issue or more urgent enhancement appears for something else that they own that no one else can handle.

Building something from scratch is a pivotal opportunity in the growth of a junior. Maximizing the growth of a junior is a long-term concern, as it eventually builds a stronger, more flexible team. However, there's a big risk when a junior builds something from scratch. Things can go off the rails, forcing a senior to go in and save the project. It would have been faster and easier for the senior to just build it in the first place.

The balance we're trying to strike is that the senior lays the groundwork and then ownership is transitioned to a junior. The senior establishes the patterns that the junior will extend. The stage at which this happens depends on the experience of the junior. For a very inexperienced junior, the senior can fully build the app to MVP, including a fleshed out architecture and code patterns. The junior is then expected to maintain and enhance it as needed. For a more advanced junior, the senior can stop after a prototype proves out that a given tech stack will support the requirements.

In practice, simply handing a project from one developer to another is very difficult and not at all clean. To mitigate this, we're trying to have more of an overlap by starting the new projects with a senior and a junior both working on it. The senior can guide the project in the right direction and impart their wisdom on the junior, so they have a firm understanding of the reasons why it was built that way. Later on, the senior peels off of the project to focus on newer things, and at that point is more of an advisor to the junior.
Ben
Thanks Johnny! This is a really great model. Just need to come up with some catchy name for it. :) It's a smart blend of "conservatorship" and ownership/stewardship...where the senior is still hands-on (not architecting from his/her armchair), but then transitions it to someone who has the capacity to own/maintain it...and that person, as a junior, benefits as well (from the challenge/responsibility of owning, etc.).

Thanks for sharing that!
Jeff
March 03, 2022
If you have six people then why on earth do you have a dozen micro services?
Ben
Haha. Fair point! Of course this is a made-up example, but I've definitely seen places with this level of granularity. That's a whole other topic though. :)

Even if it was, say 4 services, I think the problem still stands. Independent of technology/stack, there's probably a lot of non-trivial business logic/domain stuff in each of these services such that it might be tough for one developer to get their head around ALL of it effectively...and so should developers own or steward a given service they have most experience with? Or does everyone float across the 4 services?

Lastly, 6 developers was also made-up. I'd say most of us work on larger teams (maybe?), and so a dozen microservices is probably not rare/unexpected.
Daniel Aston
March 04, 2022
Agreed. An additional problem with free-for-all (which I think is equivalent to "collective-code-ownership"?) is it eliminates expertise, i.e. there is no longer an expert who knows a codebase well. Such people are valuable. Otherwise questions about how things work get the response "the last person who touched it might know".
Ben
100%! And I've definitely heard that "the last person who touched it might know" too many times to count.

This is especially a big issue as developers leave - if no one is officially designated the owner/steward of the applications/systems/components that the departing developers had knowledge of, then the free-for-all "mob" is probably just going to try to do the quickest/easiest thing possible when they need to go in there to fix a defect or add an enhancement.