This 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.
Top comments (10)
Great post. I made previous post on this topic that had its fair share of debate associated.
dev.to/ben/merged-code-belongs-to-...
I agree with all your points.
That is a common prospective that I have seen over the years. The communism parallel is a favorite for many people. I’ve seen it used to prove all sorts of points, and their opposites, sometimes in the same discussion.
That said, the issue in your group seems to be either a lack of technical leadership, lack of discipline, or both. Technical leadership in particular is what keeps things like that from happening. It is very different than individual code owenrship. You need to bring in a strong a senior technical leader AND you need to institute a code review process. Individual code ownership will not solve any of the issues you mentioned. It will simply hide them behind a “my turf” screen.
I agree with most of these points. I'm a lone developer in my office. I work on my projects and no one else works on them. However, I'd love for that to change and I'm more than open to criticism or suggestions on how to improve what I'm writing. I think that boils down more to the individual than the role. I can definitely understand how someone who works on something by themselves can get to a point where they don't want to change it (I see this at work in interactions between people not even relating to programming), however, I don't believe this can be attributed to working individually by itself. Other than that I think you made some great points! 👍
No, it is not easy, at all.
Good leadership is the difference between failing teams and successful teams. Companies invest lots of money in strong leaders, and for good reasons. It is not easy, but without it, you end up in the place that you are describing. Chaos.
Coding methodologies are a framework to help flawed humans work with more discipline. Call it manufactured discipline, in a world where humans are far from being perfect.
There is always somebody that fights against coding methodologies, leadership, etc. I'd say 10% of developers think that way. For those kinds of engineers, I recommend to not attempt to work in teams. Working in teams is difficult for some folks. It does require structure, experience, and discipline. Those are not just words, they are realities, skills, things that you build over time. Look at it this way: Mastering coding is level 1, mastering coding in teams is level 2, mastering technical leadership is level 3, mastering people leadership is level 4, and a lifelong pursuit.
Altrough there are valid points, this article is taken too far in extremes to prove your point, but I read a nice story about a such example: "We fired our top talent, best decision we ever made"
Having experts on specific modules of the projects is a good practice, but anyone can chip in anytime (code reviews, peer programming, bugfixing), there are many ways to mitigate the ownership problem.
You do not fully understand a system until you have a lot of experience with it (for example owner of the wrappers for a specific database).
You do not want all your employees to know all your 100 microservices by heart.
There are too many generally examples, for example not all Teams are better then 1 solo working, just put 3 juniors with 1 senior and you'll see that everything will go apart.
Code ownership is bad ofc, I only saw this behaviour at old projects/companies, with mediocre developers that thought this way they will make themselvs more valuable and the company more dependent on them. They were wrong ofc, it's far better to make yourself useless (example automate everything), this way you can solve other problems too, adding more value, getting a bigger paycheck, win/win. Most important, the companies I saw were not technical, the devs were just "some dudes in an office that do magic". But again these kinds of developers do not read these kinds of articles, because they do not want to improve.
And.. I can keep going, but is no use, it seems that ppl like these generic articles that describe a fantasy world, so I'll go in my corner and shut up.
Yes this article seems to paint a fantasy world. In the real world I rather imagine managers like this approach because they can force a poor guy carry the whole team by having him firefight areas other make a mess of. And the managers not have own up to their hiring mistakes or decisions or deal with the actual problem of low quality devs which may be forced on them by upper management which doesn't want to hear about paying better salaries and not hire the first guy that comes to an interview. So this way of working with everyone owning the problems(and the manager getting the credit) is a great way of sweeping the problems under the rug and not making "waves" which is what most management wants.
All of these are great ...
but this one really has a ton of truth to it.
9 – Individual Code Ownership is an Engineer’s Prison.
You, sir, got yourself a unicorn for this piece.
Great points.
Thank you :)
Huh? Let me remind you of the context we are discussing. The context is: some developers do not WANT to work in a team. They don’t want to because they are either not there yet (but they will at some point as they grow), or they are simply not wired that way. Their personality makes them unwilling and uninterested to do so.
The first answer is actually: do not hire them for a team. Why? Because a team that needs to hire a developer that can work with them cannot fight a long battle. There are plenty of team players out there that are more qualified.
If the developer is already on a team, you can try to coach them to see if they are coachable and if they are really part of that 10% or not. Some people are coachable, but some people aren’t. The context here is the 10% who do not WANT to work in a team, thus are fundamentally uncoachable. For those, if they can’t be in a team, then they should either be fired or should be given solo-type of Projects.
If I seek team members, team members I shall find. Team players are far from being “conformists.”