Individual code ownership or collective code ownership? Your choice won’t
really matter if you are missing one critical ingredient: the developers need
Empowerment and the risk of unilateral decisions
From the management point of view, it makes a lot of sense for a larger company
not to allow an individual developer to completely own a part of the overall
system. This person could be on sick leave or on holiday and cause unwanted
delays to some deliverables. He could also just leave the company altogether
taking with himself all the knowledge about the part of the code base he owns.
On the other hand, developers don’t really enjoy being considered
interchangeable resources, and they rarely are. Owning a part of the system
and have the power to carefully shape it into something to be proud of drives a
lot of developers to do great work every day. This improved sense of empowerment
can usually inspire them to care about what they are building and work on its
Just owning some code is not enough, though. It’s quite likely that a
developer inheriting some code and becoming the new owner will just want to
rip it apart. At times it can be beneficial for them to do so since it can
improve how much they will care about maintaining it moving forward.
A developer genuinely caring about his code can produce great results, sometimes
even better results than a whole team that doesn’t care about its work. That
said, having individual developers owning a code base will probably allow them
to make too many unilateral decisions, and that’s rarely a good thing.
Let the team do its magic
Having more than one developer’s input normally drives better solutions.
Brainstorming and white-boarding with colleagues can help designing a solution
together and have everyone’s buy in. Agreeing on the solution is crucial to
keep each developer engaged and make it possible for them to care enough about
the outcome of the next tasks.
Needless to say, the individuals within the team have to trust each other and
work well together, and that’s not as straightforward as it sounds.
A great team doesn’t just materialise itself from nothing. It’s usually formed
by like-minded individuals that have worked together for quite a while or by
allowing the developers to hire into their own team. If possible, random team
compositions should be avoided. For example, assigning a big ego to a team of
very humble collaborative people can cause some real damage.
The problem with complex domains
When domains or projects are non-trivial, a shared ownership approach might not
always be viable. Complex applications will naturally end up with experts
looking after them. A wider collective ownership becomes almost impossible due
to the amount of knowledge about the code and the domain developers would need
to accumulate in order to work on the project effectively.
In these cases, you will have one or ideally a couple of gatekeepers to validate
the contributions made to the projects from other developers. This also happens
quite naturally in open-source software, massive projects have a close set of
people owning them. Merge requests will be scrutinised by the core team, and
for all the right reasons.
The same principles can apply to complex systems within companies, and some
people looking after these systems are actually making great profits because of
how hard it would be to replace them. Not all skills and domain knowledge is
easily interchangeable, some can take decades to master.
Shared ownership pitfalls
In a common workplace, developers are used to sharing the ownership of a code
base with their team. At times, though, circumstances can lead to unforeseen
A developer might be away for a couple of weeks, come back, and not like the
choices that have been made by his peers. Or there might have been some
production issues caused by the last release rushed due to an artificial
deadline that demotivates the team.
A variety of other issues can occur that can undermine how much individuals care
about their projects. It can be personal issues at home, a missed promotion, a
respected colleague leaving, high management’s pressure, you name it. When
individuals within the team stop caring the same feeling can quickly spread to
the rest of the team.
Do you want me to review this code? There you go: “LGTM”, even though I think
it’s rubbish. Do you want me to hire someone into the team? Alright: “this
random guy was fine”, as long as I don’t waste any more time interviewing. Do
you want me to fix that bug? Here’s a quick workaround with no tests. Sounds
Once the team loses hope about a project’s code base and gives up on it, the
project is doomed to fail. Critical bugs left in production for weeks or even
months tell a lot about how much a team cares about its work and how much the
lack of accountability is affecting the company.
It can also become hard to pinpoint whether the project is a mess due to the
team’s skills or the individuals’ skills. Some individuals might be producing
good code while others might be producing tons of bugs that for one reason or
another aren’t caught in code reviews. With shared ownership everyone becomes
responsible for successes and failures, this can make individuals’ skills not
really visible in performance reviews, affecting the commitment of high
Shared ownership at scale
Ownership of shared code across the organisation doesn’t scale very well.
Libraries, frameworks or platforms used by different teams should have one of
the teams looking after it acting as the project owner.
This does not mean they should get to write all the code for it, but they should
at least be reviewing and be taking care of the contributions other teams make.
Otherwise, sharing the ownership of these critical components of the code base
can lead to a lack of integrity in the overall design and damage the
productivity of every team relying on it. This is probably why independent teams
tend to share very little when possible.
Be aware of the “no ownership” trap
In general, individuals or teams should have accountability and responsibility
for every part of the software code base they own. When ownership,
accountability and responsibility are not taken seriously companies can quickly
fall into the “no ownership” trap.
Code belonging to everyone is code with no real owner. Most developers will
contribute to orphan code as if writing clean, maintainable code is not part of
their due diligence. They will start applying quick fixes and move onto the next
task making a mess, sometimes a very ugly, irreversible one. Quick workarounds
can destroy the software, and in the long run, it might just be better to
officially deprecate it and get rid of it rather than keeping it around without
Another word of caution: don’t allow teams to run away from what they own
overnight. This is usually a big red warning that something is wrong. They
either stopped caring about the project or they never really cared to begin
with. Most likely, they stopped caring a long time ago and now the project might
have become too much of a burden for them to work on. This could also mean the
developers might just need some time invested in improving the code in order to
reduce the burden of maintaining it and allowing them to start caring about it
again. Asking the developers whether that’s the case is a quick and effective
way to know what is the real state of the project.
Caring leads to success
A company can hire the best developers, build the best teams, have all the right
skills in the right places and develop a great culture, but nothing will
matter if developers don’t really care about their work.
Ownership can play a great role in increasing how much we care about what we do
day to day. Most developers are self-driven and, with the right level of
autonomy, can accomplish amazing things.
It takes discipline to look after software projects over a long period of time,
and truly caring about your code can help. Ownership is critical to allow
developers to take pride in their work.
No one would clean a shared toilet, but I do hope you clean the one in your own
home, otherwise — please — do not invite me over.
I call upon everyone to start supporting the Code Care Act. It ensures that
every code base is looked after by a caring and committed owner.