Does your project have Code Ownership Culture?

This post was previously on the Pathfinder Software site. Pathfinder Software changed its name to Orthogonal in 2016. Read more.

Code Ownership is a well-known term in software development. Depending on how you define it, it may be a good thing or bad. When a developer sees code-ownership as him/her owning a piece of codebase that only he/she understands enough to make changes, it is generally a bad thing. It is only when everybody is free to modify the code with a sense of responsibility that he/she should leave the code cleaner than how they found it, it is a good thing. In my view, code-ownership is a good thing when viewed as a responsibility as opposed to a right. I view it as a Collective Code Ownership where the code is not owned by a single person or pair but is owned by an entire team.

So, the question is: How to determine if your project/organization has that collective code ownership culture. And what team members (including managers :-)) can do to create/encourage it.

Does your project have collective code ownership?
Here are few things you may want to ask yourself to determine if your organization/project has collective ownership culture.

• Are tools like continuous integration and testing, code coverage and code metrics considered nice to have but not necessary?
• Is the project release schedule determined and then enforced with little or no involvement from developers?
• Is failure to slip on iteration stories viewed as a failure on developer’s part?
• Does your velocity seem to decrease with time?
• Do developers talk about my module, your module instead of our module?
• Do members aspire to leave your project and join another project?

If answers to these questions are mostly in the “yes” range, you may have a code ownership problem.

What’s a developer to do?
Be a good citizen, strive to write good code. Leave any codebase cleaner than how you found it. Developer needs to tame their tendency to guard their masterpiece code from other people’s changes, in fact welcome those. If you really really hate some design, try to pair with the person who conceived it and influence his thought process. This might be slow and frustrating but it will be better in the long term. If you rip out everything you don’t like, you will end up owning everything. Remembership, it is a collective ownership. The code is very fluid, which means when coding, you can always take short-cuts to get stuff you are responsible for, done. Or you can take ownership and fix the general code quality (even if it take a little longer). These are all things that a developer is in control.

However, there are stuff that are beyond developer’s control. It is hard to continue to be a good citizen when other members don’t feel the same way and when your boss is holding your neck against a timeline. This is where managers can play a role.

Why does a manager care about code ownership?
A manager cares about the quality of deliverable, team morale, attrition and deadline. An agile project manager can remove obstacles that prevent such culture from growing. Managers need to cultivate a culture where developers are not hard pressed to deliver on timeline at the cost of quality, at least not often. Managers need to develop a culture of trust where developers are free to over-estimate stuff (at least from their point of view). Hire team players overs smart but solo players.

What’s an Architect to do?
Managers can’t judge the quality of code and hence the success of code ownership culture. Yes, there are code metrics like code coverage that attempt to quantify the code quality but those are not precise measures. Here is where architects can make a difference. By the architect, I mean anybody who has the direct or indirect authority to influence other developers and modify their behavior. Install tools like continuous integration, testing, code coverage and various other metrics. Encourage pair programming to reduce bus number and prevent knowledge silos (the bad side of code-ownership).

In summary, it could be a good thing when a team feels responsible when the project when in it and proud that they were part of a project that completed successfully. They owned the outcome of it, good or bad.

Related Services: Custom Software Development