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.
Best Answer
In my 20 years of experience, it is better to have code ownership rotate responsibilities amongst designers or at least have a pair of owners. Single feature ownership has the following issues, several of which you mentioned: