22

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?

Improve this question
6
  • 3
    My immediate reaction is this might work if done in moderation, but you're right about the problems if it's taken too far. On the other hand, my experience is that every feature already has a de facto owner: The last person who spent a lot of time working on it.
    – Ixrec
    Commented Jul 11, 2015 at 19:33
  • "one developer should focus (and only one)" - If you want a SPOF it is a good idea to do it that way. I recently formulated an empirical theory to the effect that the person you need the most in a certain situation ("wtf?!? why did he write it that way?") is typically exactly the one that is actually absolutely unreachable.
    – JensG
    Commented Jul 11, 2015 at 23:22
  • @JensG: meh, I have an empirical theory that the person I most frequently need ("wtf? why did he write it that way?") is me, and as such the bus factor for "remembering things that should have been written down at the time" is 0. It's just more notable when I'm blocked by someone else, because I fret about it instead of re-examining the existing code from scratch on its own merits ;-)
    – Steve Jessop
    Commented Jul 12, 2015 at 13:55
  • @SteveJessop: Sure, trying to reengineer other peoples way of thinking by examining a bunch of KLOC of their code while the customer yells at you that he needs a solution now (or else!) may be a cool idea for some people, but I'm not nerdy enough to see anything funny in wasting my time that I could be spend more productively instead.
    – JensG
    Commented Jul 12, 2015 at 14:27
  • @JensG: fortunately, my customers are better-socialised than yours. Therefore I'm not under so much pressure as to engage in the sort of magical thinking that results in a conclusion that being important to me genuinely causes people to be less reachable by me. As such, I thought there was an element of joking in what you said, so yes I'm nerdy enough to find funny a situation in which you compensate for incomprehensible code by trying to keep multiple people around who remember how it works. Especially since such wtfs are frequently my own stupid fault and not that of my colleagues.
    – Steve Jessop
    Commented Jul 12, 2015 at 14:48

2 Answers 2

Reset to default
38

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
Improve this answer
2
  • 6
    Absolutely. Important to mention the bus factor as the single most evident issue with a one-person-only ownership.
    – JensG
    Commented Jul 11, 2015 at 23:20
  • 1
    Bus factor needs to be traded against cost and YAGNI, though, and whether the bus really would cripple your organisation or just cause a lot of hassle. If it were a choice between losing, say, 3 hours a week forever ensuring that two people are educated about a particular bit of code instead of only one, or losing, say, 60 hours as a one-off for someone to bring themselves up to speed in the event one of your developers is hit, then in many cases you'd chose the one-off cost. But for the reasons stated, knowledge silos have other disadvantages more important (albeit less evident).
    – Steve Jessop
    Commented Jul 12, 2015 at 13:52
15

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.

Improve this answer
3
  • 1
    I disagree that code ownership by a single person is inevitable, but it will be owned by a small number of people. I have seen organizations that did a bad job of having shared code but did it just the same. The most effective setups that I saw were when 2 to 3 people knew pieces of code and collaborated. This reduced stress and isolation amongst the coders because they weren't on the hook on their own when things failed and lagging features could be given more attention to meet deadlines without rapid training ramps of other people in the organization.
    – Jason K.
    Commented Jul 13, 2015 at 0:57
  • 1
    @jason - sure, there should be a few people on the team comfortable and capable of working on a piece of code. But one person will end up the subject matter expert simply from working on it the most.
    – Telastyn
    Commented Jul 13, 2015 at 1:12
  • agree that that often happens, is the most likely scenario and that subject matter expertise is a good thing - only disagreement is it being inevitable simply because I have seen better success with several people being the SMEs in an area by having considerable overlap
    – Jason K.
    Commented Jul 13, 2015 at 1:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.