Summa

Introduction

There has been much interesting debate over the different practices defining who is ultimately accountable for source code. Who creates and modifies the code? What practices best foster responsibility for its quality?

Code ownership practices are just one component in an organization’s development process. Some “famous-name” methodologies recommend or require a particular ownership practice. However, many organizations (for better and for worse) don’t strictly adhere to any one development methodology… This post makes recommendations to consider when incorporating any of the code ownership practices into your team’s code ownership “policy.”

Why Does This Matter?

Code ownership practices are an often overlooked influence on your development staff’s performance. This includes the quality of the code they write, how fast they write it, how good their estimates are, and how easy it is to change the code later. It also can impact developer morale and job satisfaction.

Some Terminology

A code ownership “practice” is really just a pattern… The three practices in the section below are high level views of how different teams operate.

The term “policy” implies that a particular practice has been selected, documented, communicated to the team and is enforced in some manner or another. Don’t think of it as a large formal document - even a small internal wiki page will suffice.

When I say “good code” I mean code that:

• Meets functional requirements
• Satisfies the architectural standards of the system
• Satisfies appropriate non-functional requirements
• Is easy to read

There can be many other bullet points above (”has unit tests,” for example) but you get the idea…

Accountability and responsibility are often used somewhat interchangeably, but they really are two distinct concepts. For the sake of this post, I’ll define them as such:

• Accountability: When someone (manager, architect, lead) is empowered to reward a developer for producing “good code”… and take measures to reform/rehabilitate⁽¹⁾ a developer who’s code is “not good.” Accountability comes from outside of the individual - from the organizational structure, from code and design reviews, etc.
• Responsibility: When a developer feels accountable to his or her “self.” When a developer feels a sense of ownership over the code they write, maintain, and/or have stewardship over… and that sense of ownership inspires pride and the result is “good code.” If code is “bad,” and if they know that it is - the developer will want to fix it. No other motivation is necessary.

Code Ownership Practices

Below is a quick look at the three most common ownership practices. Please note that this is not a comprehensive examination… more information on each practice can be found by clicking its name.

Recommendations while Defining Your Policy

1. Don’t forget your goals. If you are changing an ownership pattern/policy for an existing team… why? Is it to improve code quality? Speed up time to deliver? Reduce some risk? If it’s a new system… will it be “mission critical?” Are you building one to “throw away?” Which of the architectural “ilities” are most important? These architectural factors will influence your goals. Keep your reasons in mind and measure your choices against them.
2. Measure what you’ve already got. How many team members do you have? Is the team geographically distributed or all in the same area of a single building? When dealing with an existing code base… how complex is it? How “good” is it? Measuring these types of things is not always easy but knowing where you are will help you choose where to go. In addition, when it comes to code quality, you’ll have a baseline to measure against after the policy has been adopted.
3. Ask your team for input. Do not discount the input of your staff! You need their buy-in. Do they prefer one practice over another? Are they generally in agreement or do they radically disagree on ownership practices? Remember that a strong opinion for or against one practice may be the result of good or bad experiences in an environment that does not match your own… discuss those differences instead of just writing them off. Most rational team members will agree that they will have their personal preferences, but that the environment they’re in plays an undeniable role in the success of any practice.
4. Consider the rest of your development process. Do you prescriptively adhere to a “famous-named” methodology? What does it propose or require? You probably should stick to the program or have a very good reason for not doing so.
5. Consider your source control. If you have an existing source control system… does it support the “copy/modify/merge” and/or the “lock/modify/unlock” paradigms? Ideally you don’t let your tools dictate your direction… but migration from one source control system to another without losing history can be a non-trivial project…
6. Document why alternative practices were NOT adopted. Documenting how you created the policy and why alternative practices were not adopted can be helpful in the future. Sometimes simply showing that the decision was not made arbitrarily is enough to silence criticism. Other times, if decisions hinged on certain environmental factors that are no longer valid, changing the policy could be beneficial.

Conclusions

Hopefully you and your team can hold constructive discussions on code ownership practices and create a policy that meets your goals. Each practice exists to foster “good code” — to make better software. Each can successfully promote responsibility and each provides avenues for accountability.

You will need to consider many “environmental” factors during your selection. I hope the recommendations above will assist you with your effort. In fact, all of the recommendations also apply when you define/formalize any component of your development methodology.

Don’t let the policy become “shelfware!”

A policy is worthless unless it is communicated effectively to the team, compliance is rewarded, and violations are corrected.

1: The history deviance and social control is rather interesting. Pennsylvania’s own William Penn had a hand in moving things away from a punishment-only system in the USA to one blending punishment and criminal reform/rehabilitation… Perhaps a discussion on patterns and anti-patterns for responding to bad developer behavior would make a good future post.