Is code ownership a code smell?

Question

This is something I've been thinking about ever since I read this answer in the controversial programming opinions thread:

Your job is to put yourself out of work.

When you're writing software for your employer, any software that you create is to be written in such a way that it can be picked up by any developer and understood with a minimal amount of effort. It is well designed, clearly and consistently written, formatted cleanly, documented where it needs to be, builds daily as expected, checked into the repository, and appropriately versioned.

If you get hit by a bus, laid off, fired, or walk off the job, your employer should be able to replace you on a moment's notice, and the next guy could step into your role, pick up your code and be up and running within a week tops. If he or she can't do that, then you've failed miserably.

Interestingly, I've found that having that goal has made me more valuable to my employers. The more I strive to be disposable, the more valuable I become to them.

And it has been discussed a bit in other questions, such as this one, but I wanted to bring it up again to discuss from a more point blank "it's a code smell!!" point of view - which hasn't really been covered in depth yet.

I've been a professional developer for ten years. I've had one job where the code was well written enough to be picked up relatively quickly by any decent new developer, but in most cases in industry, it seems that a very high level of ownership (both individual and team ownership) is the norm. Most code bases seem to lack the documentation, process, and "openness" that would allow a new developer to pick them up and get working with them quickly. There always seem to be lots of unwritten little tricks and hacks that only someone who knows the code base very well ("owns" it) would know about.

Of course, the obvious problem with this is: what if the person quits or "gets hit by a bus"? Or on a team level: what if the whole team gets food poisoning when they go out on their team lunch, and they all die? Would you be able to replace the team with a fresh set of new random developers relatively painlessly? - In several of my past jobs, I can't imagine that happening at all. The systems were so full of tricks and hacks that you "just have to know", that any new team you hire would take far longer than the profitable business cycle (eg, new stable releases) to get things going again. In short, I wouldn't be surprised if the product would have to be abandoned.

Obviously, losing an entire team at once would be very rare. But I think there is a more subtle and sinister thing in all this - which is the point which got me thinking to start this thread, as I haven't seen it discussed in these terms before. Basically: I think a high need for code ownership is very often an indicator of technical debt. If there is a lack of process, communication, good design, lots of little tricks and hacks in the system that you "just have to know", etc - it usually means that the system is getting into progressively deeper and deeper technical debt.

But the thing is - code ownership is often presented as a kind of "loyalty" to a project and company, as a positive form of "taking responsibility" for your work - so it's unpopular to outright condemn it. But at the same time, the technical debt side of the equation often means that the code base is getting progressively less open, and more difficult to work with. And especially as people move on and new developers have to take their place, the technical debt (ie maintenance) cost starts to soar.

So in a sense, I actually think that it would be a good thing for our profession if a high level of need for code ownership were openly seen as a job smell (in the popular programmer imagination). Instead of it being seen as "taking responsibility and pride" in the work, it should be seen more as "entrenching oneself and creating artificial job security via technical debt".

And I think the test (thought experiment) should basically be: what if the person (or indeed, the whole team) were to vanish off the face of the Earth tomorrow. Would this be a gigantic - possibly fatal - injury to the project, or would we be able to bring in new people, get them to read the doccos and help files and play around with the code for a few days - and then be back in business in a few weeks (and back to full productivity in a month or so)?

Answer 1

I think we must make a difference between code ownership:

• from the responsibility point of view,
• from the code style/hacks etc. point of view.

---

The first one must be encouraged. If nobody is responsible for low quality code and bugs, bad things will happen. It doesn't mean that the bug related to your own code must be assigned every time to you: if the code is correctly written, anybody can fix the bug in any part of the code. But if you don't have any feedback about the bugs you do, you'll produce the same bugs again and again.

Code ownership may help a lot both the managers and the developers, especially the developers. If I know that 80% of bugs in the product were in my code while we were three developers working on the project, and that 75% of those bugs were related to SQL Injection, I would be more careful writing code the next time, and make an extra effort to write database queries correctly.

---

The second one (code ownership from the code style/hacks, etc.) is mostly a bad thing. What does it bring to the product? It does not increase the quality of the product, but decreases the uniformity of the source code and makes it difficult to maintain it lately.

For many large projects, people don't stay for life working on the same piece of code. And here, I don't even talk about horrible things like the developer being hit by a bus: I don't think code ownership is the first concern in this case. But lots of minor thinks happen: people migrate from development to management or other jobs, or choose other projects, or work on other stuff, or start using another language (if several languages are used inside a project), etc.

A piece of code of a project can also be reused in another project, and the developer working on this other project would like to modify some parts of the code to fit the new needs, without asking for advice the former writer of the code.

Is it a code smell? Well, it depends on what do you mean by code smell. For me, it's all about the overall coherence of the project and correct management. In a good project,

• code style guidelines are enforced to help to understand the code easier later,
• more experienced developers do not violate the KISS principle, thus helping the understanding of the source code later by the less experienced colleagues.

To conclude, code ownership must be tracked through version control, but you must not be able to say that a piece of code is written by you or somebody else in a team.

Answer 2

First we need to define what is "code-ownership".

---

When a piece (part) of code is in the early process of being developed, often it is necessary to designate one or two persons as the "owners" because:

• In the beginning there is no clear specification or requirements, and the developer(s) will need to collect information on their own. There is a time gap between the collection and the documentation of those findings.
• Avoid conflicting edits when the piece of code is being actively modified.
• The "owner(s)" are the person(s) who can report the progress of the feature's development.

Normally there is a single owner for each task. Dual-owners are possible with Pair-programming. It would not be practical to do it without any narrowly-designated "code-ownership".

Note:
Please see @MainMa's answer for the other issues during development. In those cases, "code-ownership" is a symptom of bigger problems, that is: suboptimal choice of architecture, coding style inconsistency, and generally lack of code quality.

---

Once a piece is written and accepted into the code base ("done"), the more general "code-ownership" question appears.

• Who is the expert that can answer all questions about this piece of code / this part of functionality?
• Has this knowledge been captured in tangible artifacts, such as requirements document, unit tests, acceptance tests, change logs, project wiki etc?

There will always be some part of domain knowledge (tacit understanding of customers' requirements, compatibility problems with arcane systems, etc) that are hard to formalize into written specifications. Therefore, when there is a calamity event, some loss of domain knowledge has to be expected.

Along with the loss of domain knowledge, you will also lose the expert answerers who can explain the details of the system. In this aspect, loss of the expert is a universally bad thing. The knowledge should have been captured earlier.

This does not mean that the existence of "experts" is bad: Consider experts to be a "cache" of the written knowledge. Experts can often answer questions faster than having to look up and digest written knowledge.

---

However, sometimes "code-ownership" refers to barriers set up by a project's active developers to prevent outsiders from modifying the code.

• Who can make changes to this piece of code?
  • To fix obvious bugs?
  • To make the code satisfy some other requirements?
  • To completely rewrite the code to one's taste?

There are good barriers and bad barriers:

• Good barriers
  • Domain knowledge - how well you understand the requirements and the architecture / coding style
  • Programming and design skill - do you have the skills to improve the project's design and code quality
• Bad barriers
  • You were not on the original developer team, so you are not allowed to make changes.
  • Only bugfixes are welcome. Feature enhancements are not welcome.

In this case, the privilege to edit other project's source code should not be based on code-ownership, but it should be merit-based.

---

Finally, @Graham Lee's answer points to the fragmentation of knowledge and architecture that is caused by departmentalization.

In this case, "code ownership" is one of the symptoms of departmentalization. A second symptom is the "lack of interest in other team's projects". As an organization, the managers will need to take steps to encourage knowledge transfer and collaboration across teams and departments.

Answer 3

More insidiously, some companies (I've worked at one) organise their management structure around functional teams: you manage the Windows client developers, she manages the installer team, he manages the backend devs and so on. Not only does this lead to the strong code ownership you describe, it enshrines it as the way the business works. It turns the software architecture into a political bunfight.

Is this a problem? It is if the architecture is-or becomes-suboptimal. It's impossible to say (for example) that the installer would work better or be cheaper to develop if it were just a use case of the client, because that's taking control away from a team and its manager. The divisions between functional modules have become facts about the way the engineering department is run, and it takes a lot of upheaval to alter those facts.

[BTW in case the above discussion doesn't make it clear, my answer to your question is yes. Code ownership is a code smell, because it can stop clever people with good ideas-or even just people who are available when you need them-working on the code. Obviously having controls to stop capricious changes is a good thing, but if you have an engineer who can see how to fix a bug and has the time to do it, you shouldn't block that engineer just because somebody else wrote the buggy code.]

Answer 4

Tackling your question from a slightly different point of view, code ownership is NOT a code smell. It is instead a management and resourcing smell.

Think about what a code smell means. It's a metaphor that tells you when you look at your code, that something isn't quite right with the code and/or the design of the software, but the problem may not be so obvious as to be able to put your finger on what the exact problem may be but you've probably got a good idea regardless. In your home, if something smells bad, you follow your nose until you locate the source of the problem, and then you do something about it. In the same way, if the code has a problem you investigate and change it until it becomes less of a problem, or as some might say, beautiful or well-crafted.

Code ownership on the other hand can be a serious problem. It suggests a lack of oversight, and a risk that if the code owner leaves, that knowledge about the code and the specific problems that it solves will no longer be available to the company. This has nothing to do with the actual code itself. It basically comes down to a risk management situation in the same way that leads us to keep backups of our data, and applies just as equally to task ownership, or document ownership in other areas of the company.

I think that it's fine to describe other business problems as smells, but certainly not to imply that just because there is a smell, that it has specifically to do with code.

Answer 5

I define Code Ownership as taking personal responsibility for the code that you write, with the understanding that others will be working in your code in the future. If you think of things in this way, you'll be less likely to write a hack because a) bugs in that module could be traced back to you, and b) team members would likely have a hard time modifying the code in the future.

I wrote a blog post on this several months ago, where I argued that without code ownership, as I define it, a codebase often falls prey to the Tragedy of the Commons.

By your definition of code ownership, I agree that it's bad to have code that only the author can work in.