...and can the answer be "it depends (...on the size of the software)"?
Let's think about this question from the other end - who gets all the blame and praise? If a tool or component is so small that it can easily be written completely by a single developer, everybody will probably know its author, because he's the one who gave it to you or even presented it at your last team meeting, where he has received a lot of praise from management for writing it. So you just go to the author and ask him to implement a feature for the next release. Code ownership comes naturally for small components, scripts, and tools that are too small for an additional product owner or demand process.
But if the software is too big for a single developer, if it can only be the result of a team, no single developer will feel code ownership for the complete product. So who will care for things like coding style and test coverage? Do we all care by choice, because we're professional? Or do we need processes and/or a product owner to enforce good code quality?
Good point - I agree the tendency is often to speak to the code author on small components for
future feature developments but this often leads to knowledge silos.
A potential way around this is the use of agile as the development process, the breaking down of small tasks will encourage a dev team to 'swarm' over even small pieces of work so everyone gets eyes on it. This coupled with strongly enforced code reviews by the team could potentially help. The tradeoff is it will probably take a little longer on smaller bodies of work because of process.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Is code ownership good or bad?
...and can the answer be "it depends (...on the size of the software)"?
Let's think about this question from the other end - who gets all the blame and praise? If a tool or component is so small that it can easily be written completely by a single developer, everybody will probably know its author, because he's the one who gave it to you or even presented it at your last team meeting, where he has received a lot of praise from management for writing it. So you just go to the author and ask him to implement a feature for the next release. Code ownership comes naturally for small components, scripts, and tools that are too small for an additional product owner or demand process.
But if the software is too big for a single developer, if it can only be the result of a team, no single developer will feel code ownership for the complete product. So who will care for things like coding style and test coverage? Do we all care by choice, because we're professional? Or do we need processes and/or a product owner to enforce good code quality?
Good point - I agree the tendency is often to speak to the code author on small components for
future feature developments but this often leads to knowledge silos.
A potential way around this is the use of agile as the development process, the breaking down of small tasks will encourage a dev team to 'swarm' over even small pieces of work so everyone gets eyes on it. This coupled with strongly enforced code reviews by the team could potentially help. The tradeoff is it will probably take a little longer on smaller bodies of work because of process.