A complete guide to Codebase Ownership

• How fast can we deliver changes to the market?
• How reliable & easy to maintain our solutions are?
• How easy it is to scale the team / organization?

Code ownership is tied to all of these questions. Measuring & shaping it reaps the long-lasting benefits for your organization.

Practical knowledge can only be gained through work:

• Doing bugfixes, refactoring, or new features;
• Participating in code review;

Codigy detects behavior patterns of both these events through git and builds an interactive Confidence Map for you. Here are the most important concepts to grasp:

Responsibility shared between teams

Codigy seeks ultimate maintainability, which dictates that a file should have a single purpose. If a file is actively modified by two or more teams, it's an indicator that it should be split.

Overcrowded areas

The whole purpose of the digital workspace is to allow people to work simultaneously without interfering with each other.

Splitting such files will increase the reliability and maintainability of this area.

Owners & Co-owners

Engineers who have recently introduced or modified a significant portion of the area.

Owners ensure order & co-owners increase knowledge resilience. As long as they belong to the same team, having these two roles within an area is ideal.?

Occasional contributors

Exactly as the name suggests, engineers who have some working understanding of the file through more or less regular contributions.

They don't directly contribute to the reliability of maintainability of the codebase, unless:

• If there is too many of them, which isn't great as it makes the file overcrowded
• If the file doesn't have an owner or a co-owner, they are good candidates to become one

Micro changers

Multiple contributors are doing small, sporadic changes? It's a clear smell of architectural coupling.

You can verify this through the Maintainability map, and consider splitting the file to increase the maintainability of your product.

Lost knowledge

Areas of the codebase that weren't modified over 6 months or owned by contributors who left the team.

A continuously growing amount of lost knowledge is an alarm bell for long-term product resilience.

Practical instruments of improvement:

Code splitting & strong review culture are the quickest remedies. In some cases, more advanced interventions are needed:

• Domain rotation - in smaller teams, domain knowledge can be reinforced by occasional rotation. A change of scenery can be refreshing for the team??
• Team scaling - products outgrow the size of the team all the time. Your team could be stellar but there is only so much we can do in a week. Accumulation of lost knowledge is your tell.

The Confidence map is an x-ray lens of knowledge sharing and ownership within your organization.?

Team behavior patterns within the codebase are tightly related to maintainability, acting on Confidence insights will lead to architecture with higher efficiency.

FAQ:

How is the map structured?

The map file hierarchy and metrics are based on a selected long-lived branch i.e. Main or Staging (depending on your process).

How often map is updated?

The map is updated with every commit/merge into the selected long-lived branch.

What about files that are not expected to change??

A confidence map is intended for code areas that are maintained by your teams. External libraries, autogenerated & binary files can be excluded from analytics.

---

Questions & discussions are always welcome in the comments or in our Community Discord channel ?? https://discord.gg/h74vjkY