Lorenzo PasqualisThis post was first published on CoderHood as 12 Reasons To Avoid Individual Code Ownership. CoderHood is a blog dedicated to the human dimension of software engineering.
Coding is a form of art, and artists are very attached to their pieces. That visceral attachment is what makes programmers passionate and intense. That can be a good thing, but it can also lead to problems.
Unless the entire development organization has only one or two developers, individual code ownership is a dangerous disease. I do not recommend it, nor encourage it for many reasons.
#1 – Emotional Attachment to Code Hurts The Collective Wisdom.
Programmers that identify with their code become attached to it. That emotion causes code to become untouchable by anybody else, and it generates dogmas that grow into turf wars. When emotions are involved, code reviews are difficult. It becomes impossible to make improvements unless the owner of the code approves the changes.
I look at software engineering organizations of 3 or more as teams playing a team sport. That sense of team should expand to the ownership of the artifacts generated, the goals, the process, the way success is measured and celebrated, and all other aspects of the work. Each player in a sports team doesn’t own victory. The team collectively owns it. Each member is an essential part of a single organism that can get the job done. It is the team that wins a game, not a player. Similarly, developers should not feel as they own the code. Instead, they should feel like a necessary part of building that code, playing the game for the organization, not themselves.
As every aspect of an engineering culture, this way of feeling about code needs to be encouraged from the top, ideally at the very start of an engineering organization. If the encouragement is successful, that culture will form down in the trenches and become a reality. Check out my post about company culture for more thoughts on how to influence the formation of culture.
#2 – Individual Code Ownership is a Single Point of Failure.
Developers get sick, they quit, get promoted, move to other departments, move out of state, die.. you name it. Having important parts of a company’s IP tied to one person is a one-way lane to disaster. Individual code ownerships ties the health of your company to the health of the owner of the code, or the health of the relationship between that owner and the company.
If one developer owns the code, that developer is a single point of failure. If anything happens to him or her, the organization is left to deal with the consequences. The more complex the code, the more damage the company has to absorb, and the longer it takes to get back on track.
#3 – Teams Are Stronger Than The Sum of Their Parts.
One talented developer can create incredible value, but a team of N developers can create more than N times that value. Brainstorming, collaboration and feedback improve the quality and output of any developer, no matter how talented he or she is. When one individual owns the code, brainstorming and collaboration become secondary to the ownership, and the results affect the quality of the product.
It is a fallacy to think that a few developers working solo are better than a small team working together. One developer working solo might generate some practical result quicker, which is great for a prototype, but the quality and longevity of the result is going to be limited, which is not so ideal for business.
#4 – Code Is a Product. The Organization Owns It.
Nobody will have problems determining if a house belongs to the carpenter who built it, or to the homeowner who purchased it. That is because a house is a physical object, and has physical qualities that we see as something that the buyer owns. When you buy food at the store, that is your food. If you buy a car, that is your car. Pretty obvious!
When a product is conceptual, things are not so obvious. For example, a writer of a novel owns the story, while the buyer of a book owns only the paper the novel is printed on. Software is closer to a concept than to a physical object, and developers, especially in small companies, feel like they individually own it. They feel that way because they are the only ones understanding it in details. It is a natural tendency, but also a fallacy that both organizations and developers should keep away from.
Software is owned by the company, not by the developer who wrote it. Legally that is a fact stated in most employment contracts between software developers and their employers, but the way people feel day to day can be very different. While the engineering team should feel a sense of responsibility for that work, the developer should not feel a sense of individual ownership.
#5 – Innovation Takes a Village.
If one developer individually owns the code, that developer is expected to do all the innovation. Sounds ridiculous? It is! As a single engineer flying solo, you can, indeed, create quick innovation, but soon you hit a point of diminishing returns. A team, on the other hand, continues to innovate through collective wisdom, brainstorming, looking at a problem from many different directions, and bringing to the table a wealth of experiences that one single person cannot have.
If the team changes over time and new people with different experiences are injected into the mix, the quality of innovation grows, and new concepts generation rekindles. Debate and benevolent friction spur innovation; secrets and carefully guarded domains of knowledge do not.
#6 – Individual Code Ownership Causes Stagnation.
Lack of innovation causes stagnation. Coders that work in isolation for prolonged periods of time tend to fall prey of confirmation bias for ideas they became accustomed to. They will get to a point where they refuse to accept any change to their work because concepts have acquired a tangled significance to them. Any idea or influence coming from external sources end up being filtered and dismissed if it doesn’t agree with previous decisions.
Working this way for a period, particularly in the beginning of a business venture, could be a good thing. Eventually, however, this way of developing software stops scaling, and innovation dies quickly. Stagnation is the fierce enemy of the solo developer and must be fought tooth and nail.
#7 – Individual Code Ownership Prevents Personal Learning.
Developers who spend their entire day working alone on the same codebase for prolonged periods of time become pigeon holed. That means that they become rusty in anything that is not their area of expertise, and stop growing.
I have seen developers coming from big business who have worked for years on the same dialog box of one single application (some departments in Microsoft used to be notorious for this). That kind of specialization is the result of extreme individual code ownership, which leads to loss of personal growth.
#8 – Individual Code Ownership Prevents Career Growth.
If one developer grows attached to their code, they are not only a single-point of failure as seen above; they are also difficult to advance to higher level positions, as there is no easy way to substitute them for the work they are responsible for.
I have talked about this before in a post titled “Work yourself out of your job.” To be promoted you must give away your prized possessions, and work yourself out of your current job so that you can start a new one with a higher level title. Individual code ownership limits that possibility. The first thing developers need to do to be promoted is to make sure they are not individual owners of some part of the code base.
Individual code ownership is often self-inflicted and can be easily reversed. To do so, developers need to embrace and encourage other engineers to touch the code they wrote, and help them become familiar with it. At first, it will feel risky to let that ownership go. It will feel like you are pushing yourself out of your job, but that is exactly the right thing to do to move on to different and better things.
#9 – Individual Code Ownership is an Engineer’s Prison.
Feeling indispensable as the result of “owning part of the code, might give the false impression of what some people refer to as job security. However, that job security looks more like a prison cell than a comfortable place to be. Without learning new skills, and without career growth, a software engineer is locked up in a self-made prison that tends to get smaller and smaller.
A few years ago I read an excellent article titled Give Away Your Legos, and Other Commandments for Scaling Startups. It talks about the scalability of startups; the same concepts can be applied to personal scalability and career growth. A developer who is keeping their lego pieces next to them, guarding them carefully, is building a prison cell Lego-brick by Lego-brick. Give away your legos to reinvent yourself and move forward.
#10 – Developers Who Cling to Their Code, Clash With Leadership.
In the technology world, market realities change all the time, and so do products. Sometimes product changes must be radical, and developers need to be able to adapt and support the changes requested by leadership. When the sense of personal code ownership is too strong, developers tend to fight with leadership and resist change. That behavior can cause a clash that ends up either slowing progress or getting developers fired.
In some large organizations, entire teams are fired because projects are canceled. Think about that for a moment. Why would a company fire an entire team of talented engineers just because a project is canceled? If the engineers were able to move to new projects without problems, do you think the company would fire them? The reality is that, sometimes, teams are formed around projects. Individuals become engrossed with the project, owning it and guarding it carefully, losing the ability to adapt to new things. Refusing to change and let go is not only a prison; sometimes it becomes a professional coffin.
#11 – Individual Code Ownership Leads to Mistrust.
A developer who feels the need to own and defend a code base is broadcasting an unhealthy message:
Keep out! I am the only one who can understand or touch this code.
That message might not be explicit, but it is felt throughout the engineering organization and consciously or unconsciously recognized as a sign of mistrust. When members of the same team do not trust each other and make that clear, the team suffers and loses the ability to move swiftly. Mistrust causes unhealthy friction, which burns precious energy without generating any positive results in return.
When developers start feeling comfortable working on the same codebase and let go of their sense of individual ownership, things change. Trust becomes part of the way of working, and teamwork becomes the driving force. Teams operating in an environment rooted in trust generate better results and become more resilient.
#12 – Refusal to Subscribe to Organized Development Processes Doesn’t Scale.
Developers who feel like they individually own the code, often feel like they do not need any process to guide them. Agile methodologies such Scrum or any other form of organizational structure seems foreign and unnecessary to those developers. That is not dissimilar to an artist who refuses to work under any pressure, structure or constraint.
That view of software development is rooted in the early hacking days so typical in the life of a young developer. During those days spent flying solo, learning happens organically. Long hours dominate the life of a programmer, and processes have no meaning in a team of one. That way of working is not scalable. When more than one or two people are involved in a project, the methodologies used during the glorious hacking days no longer work.
In organizations where developers operate as part of a team, the process becomes an important tool. It is instrumental to synchronize efforts and to ensure efficient, predictable and organized delivery of results. There is a huge difference between hacking and developing software. While the former might be fun, the latter is how engineering organizations scale.
