When is shared code ownership useful?

Question

I've worked on several projects lately that have promoted the idea of shared code ownership. At times, this seemed to speed up code-improvement and enhancement. Other times, it seemed to become a ground of ego-jousting with changes being made to support individuals coding styles, favored technologies, or simply a demonstration of power/intellect.

How can shared code ownership be implemented to avoid the pitfalls and still reap the benefits? Can too many cooks spoil the broth?

Answer 1

Coding standards can certainly help, especially if backed by continuous integration and/or source control check-in policies.

First, define standards and get the team to agree on them (management breaks ties).

Second, use automated tools (preferably with IDE hooks) to handle code formatting.

Third, use automated static analysis tools to check compliance. These can go beyond validating formatting and check code complexity metrics, naming conventions, best practices, etc. The better ones can be customized to match your team's rules. If possible look for ones that allow suppressing inappropriate warnings via metadata (such as attributes). Most rules have exceptions, and you want to hide the "noise" of false positives.

Fourth, integrate the static analysis with your source/revision control system so that it's run on check-in. Some systems permit rejecting check-ins that do not pass policies. Another option (not mutually exclusive) is to set up a continuous integration server that auto-builds on check-in; it can run static analysis and notify all developers on any failures.

Answer 2

I found shared code ownership to work well when combined with issue tracking and coding guidelines. Ie people work on issues (assigned during dev meetings) which can involve anybodies code and a lot of "style" questions addressed in the guidelines. This seems to be quite effective and does not seem to have the problem you mentioned of people changing code for no good reason.

Answer 3

• Communicating through pairing, tests and clean code: When you don't have loads of time to write technical documents or when the system is changing so much you can't keep up with the need to write technical documents.

• Agile teams don't have an "architect figure" that dictates exactly how everything fits together. Agile team members have a much more democratic take on things and design is collaborative. This means more communication, and a type and volume of communication that would be difficult to sustain only through written documents. (Not to say you don't need documents - but that pairing face-to-face and shared influence on direction is necessary.)

• Shared ownership is useful for distributed teams that need to share a common core codebase. On a distributed team I worked on, we sent remote collaborators to our HQ to pair with us on the common code, so that they could gain enough knowledge and confidence to work on it at remote sites whilst the original authors of the code are sleeping in a different time zone. Result: less need to wait for remote experts.

• You are building something that requires several different types of expertise, and no single team member is an expert in all of those fields.

• The project intergrates two or more complex subsystems and experties in each subsystem is unevenly distributed amongst team members.

• Implementation is by a subcontractor, but some other group will adopt the system and maintain it. Both parties need to be pairing and influencing the direction for this to be sustainable.

Answer 4

Shared ownership has many benefits. Below are the idealised points, but you can get a long way towards them, especially as a team knits together over time:

• Many brains are better than one. Coders will often spot mistakes or question oddities in each others code, thus improving the overall code robustness. Think of it as continuous peer code review.
• Lowers risk of losing critical/valuable knowledge if a developer is hit by a bus or resigns.
• If a developer is on holiday for a week you don't have to wait for a week for a bug to be fixed. Or you don't have to explain to an angry coder why you messed with "his" code while his back was turned.
• Spreads product knowledge across the team. A guy calling a library will make fewer mistakes if he actually worked on the code in the library and understands it well. A guy calling a black box he knows nothing about will take longer and make more mistakes.
• Spreads coding knowledge across the team. Everyone learns tricks and patterns from others (even top programmers can sometimes learn something they didn't know from a junior)
• Evens out the coding style - people have egos and tend to like starting religious wars, but if they work on the same codebase and the manager enforces the coding standards and intervenes to keep "fights" over style under control, after a while the team starts to work as a coherent group, code quality increases, and the fights stop happening.
• Helps everyone feel they are part of a team, with no loose cannons. There are no primadonnas and everyone feels they are equal and their input is valued and worthwhile - this translates into better self esteem. In addition, when the team achieves a goal, everyone feels good about it, and when the team fails, nobody feels the full weight of individual responsibility.
• Programmers communicate more, which gets you a better team spirit and a greater willingness to help others.
• It improves code quality because programmers know others will be reading their code, so they tend to leave it all in a much tidier state to avoid embarrasment. THey also know that they have to make their code easy for others to understand, so they start writing code for others to maintain, rather than writing code for themselves.

Answer 5

I think the fixes are:

• Coding Standards, eliminates aesthetics fights and has numerous other benefits.
• Common Commitments, if someone is making changes that doesn't improve the design or implement some required functionality then the team should be calling them on it. After all, if you are blowing time posturing rather than proceeding towards the goal you're impacting the teams performance. Peer pressure can then take its course.

You should also assess yourself. There is a natural tendency to believe that actions which one doesn't agree with are irrational. Quite often one just lacks the experiences that are motivating the other, and sometimes one has to get past their own ego investments.

Answer 6

I had both good and bad experience with shared code ownership.

It feels good when:

• Code is used by several people, like utilites and interfaces.
• Programmers have comparable qualification and knowledge level.
• All owners need something from shared code.

It feels bad when:

• Code is not stable (when prototyping or refactoring). Owner should stabilize it first.
• Enforced as a policy. Team will simulate it and hate the enforcer.
• Code is badly written. It needs to be fixed, not shared.

In general, shared ownership of everything is not good idea. Better to share when it feels natural, and keep code for yourself when it does not.