Code Care Act
Individual code ownership or collective code ownership? Your choice won’t really matter if you are missing one critical ingredient: the developers need to care.
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 continuous improvement.
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 crises.
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 familiar?
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 performers.
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 owners.
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.
