Is feature ownership a good practice?

Question

Recently in my company it has been suggested that one developer should focus (and only one) in one feature. That would mean something like setting the developer aside of the normal team routine, releasing it of some other responsibilities (meetings and such) and this person would be the "only" responsible for the feature, technology wise.

For the record, we use SCRUM within SAFe, and we have for full time developers per team, sharing QA and product owners between our two teams (Android and iOS).

While I agree that this would increase productivity in a short term, I have the feeling (and I think I learned it in the university) that this is a bad practice for many reasons:

• Code review loses value.
• Minimal knowledge sharing.
• Risk increment.
• Loss of team flexibility.

Am I right or it's not a bad practice at all?

Answer 1

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:

• it tends to pigeon hole designers and limit their growth opportunities
• it puts all the eggs in one basket so if someone is hit by a bus or quits, there can be a hole in knowledge
• a single person may not see an issue in the code and without a peer owner code reviews are far less effective
• it is hard to maintain code consistency and readability if everyone is working on code using their own style - while this can be worked around with style guidelines, subtleties can creep in especially when using convention over configuration where people are relying on default behavior
• developers can tend to become protective and defensive of their code if they own it which can inhibit evolution of code - if several people own it, this tendency is reduced

Answer 2

Feature ownership is inevitable, and done well can be a good thing. It help builds mastery and allows autonomy - two of the generally recognized pillars of engagement. It makes it clear who has the accountability for that code, and aids in delegation, communication, and otherwise getting shit done.

But you're not talking about that. You're talking about making a new team of one - cutting this person off from the rest of the code. That is not great. It limits their career. It adds risk to the project/company. It harms comradarie.

So some moderation might be in order to turn this away from a bad idea.