Avoiding code ownership

Introduction

Kenneth Truyers

Avoiding code ownership

Avoiding code ownership

Creating development silos, is a practice I have seen in many different teams. What I’m talking about is having developers specialize in parts of the domain, i.e. one developer handles all the code related to invoicing, another one does everything around order management, etc. It’s a natural tendency to select the same programmer for the same part of the application all the time. The reason is that it creates immediate and tangible results. Assigning the developer that has most knowledge of the code at hand, is the one that will complete the task as fast and as good as possible.

However, in the long term, I believe there’s more benefit in doing the exact opposite. Although counter intuitive, I think spreading the knowledge of the domain throughout the development team has a lot of advantages.

Knowledge sharing

If you assign a task only to a developer that has worked on a feature before, you concentrate the knowledge of that part of the domain in that developer. While having a lot of knowledge is good for a single developer, it’s not good for the team. Having the knowledge spread out over the team unlocks a bunch of advantages:

Consistency

Initially, a developer with more knowledge of the code will complete a task faster. That is a logical fact. The same is true for the opposite: if you give the task to a developer with no knowledge of the code at all, it will take him considerably more time and effort to complete it. In an ideal world, a team is always the same size and no one ever leaves, takes holidays or is off sick. In reality however, teams change, have other responsibilities and are in general not constant.

By having knowledge concentrated on a developer/feature basis, you will see a lot of highs and lows in the productivity of the team. The highs occur on moments that the team is in a stable period with no one leaving the company, no sick days and/or holidays. The lows happen when someone leaves. All of a sudden a lot of knowledge has left the company and someone needs to pick that up. The same happens when someone goes on holiday. In a way, a holiday is even worse, because the rest of the team will just sit and wait to start “that feature that touches invoicing” until John, who knows all about invoicing, is back from holiday.

If you spread the knowledge however, you will eventually get to a point where development speed is consistent. Holidays are spread over the year and the team just picks up any work that’s available. The same happens when someone leaves the company. What’s more is that a new developer can be trained by anyone, not just by that one other guy who also has the knowledge required (provided there IS actually another one around).

Responsibility

If you know that no one will look at the code you’re writing (at least not until you’re gone), there’s a natural tendency to get sloppy. Conversely, knowing that this code will be viewed tomorrow by your colleague tends to put you on edge. This is not just because developers are sloppy or because of a bad developer. To some extent, every developer is prone to this, regardless of how good or professional they are. It’s simple human nature.

Communication

Having shared knowledge moves code ownership from the individual to the team. With everyone at the same wavelength, it will improve communication within the team, and mistakes will get picked up by the team, not by individuals. Individuals can have good days and bad days. A team usually zeroes that out.

Code Reviews

If you’re doing code reviews (and you should: https://www.kenneth-truyers.net/2016/04/08/code-reviews-why-and-how/), rotating the team will also improve their quality. If you review code of which you have never seen the context, it’s a lot harder to assess the quality. Either it takes a lot of time to review, because you have to read and analyze all the surrounding bits, or, more likely, developers tend to think, “looks decent enough, I suppose that’s handled somewhere else”.

If you know the context, it’s much easier to spot bugs, suggest alternate patterns and provide valuable feedback. Without knowing context, code reviews are often reduced to formatting checks, something that’s better left to automation.

Code Quality

By having a broad knowledge of the entire domain, chosen solutions tend to fit better into the whole. It’s easy to provide a narrow solution for the problem at hand, but it’s very difficult to provide a generic solution that will be scalable in light of where the business is heading. By sharing the knowledge, you prevent tunnel vision.

Developer Satisfaction

Development is a creative activity. Nothing kills creativity more than repetition and boredom. By working on the same part over and over again, developers get bored, leave for other, more exciting places or simply go into standby mode, doing what they need to do and nothing more. By having people work on different parts, they will feel more as part of an organization, an idea and can see the goals. That creates a motivating environment and will make them want to do the best possible job.

Planning

Related to the point on consistency, planning workload also becomes a lot easier. You no longer have to check each developer’s schedule and you don’t have to cut out requested holidays (which also helps for developer satisfaction). Because there are multiple developers who can do a job, you can just assign the task to any developer that’s available.

Terms and conditions

Rotating the team around features has a lot of advantages, as explained above. Obviously, don’t take this advice to the extreme. Don’t let your DBA design your front page, don’t let your UX specialist optimize DB queries and, for the love of god, don’t let your PR spokesmen implement your log in page.
Developers all have their specialties, that’s OK, but they should be technical specialties. What you want to avoid is that developers become specialists in a thin slice of the domain.

Another thing to keep in mind is the team size. I’ve found the above guidelines to be useful in small teams. Once your team grows beyond 7-8 developers, I prefer to take the other extreme: separate the teams. The boundaries between the knowledge should be more clearly defined and any team should consider code by a different team as if it were third-party code. This allows teams to be very focused. It also means that external interfaces should be very clear, well documented and above all, stable.

Conclusion

Sometimes doing the non-intuitive thing, is more beneficial than doing what seems natural. Rotating a team around features increases consistency, code quality, responsibility and developer’s satisfaction. While going for short term wins might be tempting, the long term benefits are clear.