5 ms·

It's usually a bad idea to have code "owners". Yes, sometimes someone will know the most about a specific piece of code if either they wrote it or worked on it

It's usually a bad idea to have code "owners". Yes, sometimes someone will know the most about a specific piece of code if either they wrote it or worked on it a lot. Sometimes people will not want to touch a piece of code. My rule is that once you submit the code for review and it passes and gets merged everybody owns the code. Everybody. The person who is modifying the code has the responsibility to identify the best reviewers (by looking at history, chatting with others, etc) to ensure high quality and understanding.

breischl 8y ago
Some people have claimed that in my organization. I think that can work for library code, and particularly libraries that are used in many different places. But once you're talking about a service, or code that is only used by one service, then you need to have an owner (or a team of owners). If you still think there's no owner, then ask yourself who is going to get woken up at 2AM when it breaks, and that's your owner.
- mirceal 8y ago
  the team owns the code. the whole team. whoever is oncall gets to wake up at 3am if there is an issue.
  - breischl 8y ago
    That works OK-ish for small organizations. When you have 1000 engineers, or even 100, it is no longer feasible to have a single on-caller who can keep up with changes enough to debug every system, much less the multiple on-callers you need in order to have an on-call rotation. IME even in small organizations (<20 engineers) it's very easy to end up not knowing enough to debug everything, and your on-caller basically becomes a smart router. ie, they can debug enough to figure out that it's a DB problem, and then wake up the DB guy. This becomes really annoying for the on-caller, so there's an impetus to have more focused paging groups, and now you're back to having owners for services.
    - mirceal 8y ago
      nope. you need to know how the thing that you're responsible for works. no exceptions. what you can have is an interface to another service/team that represents the boundary of your service. When shit breaks and you isolate the breakage to this dependency you wake them up (preferably you detect and you raise this automatically). bonus point if you thought about this as you were building your stuff and your service can work in degraded mode while the thing is solved. owners for services if okay as long as owner == team. if owner == individual you're doomed + people owning critical things will hate you and their job.
      - breischl 8y ago
        >owners for services if okay This is pretty much the exact opposite of your assertion at the beginning of this thread, to wit: >once you submit the code for review and it passes and gets merged everybody owns the code. Everybody. Anyway, this last comment I agree with entirely, and is pretty much what I've been saying all along. So I'm glad we can agree. >you need to know how the thing that you're responsible for works Agree with this as well, but a critical point is that "the thing you're responsible for" may be subset of "everything" in your organization. Maybe even a relatively tiny subset, in a large organization.
        mirceal 8y ago
        yes. everybody in the team. i sure hope there aren't places out there where you have thousands of people each responsible for millions of lines of code. my point was that you should not have individual code ownership and individual gatekeepers. I can see how that might be misinterpreted.
  - pmiller2 8y ago
    What happens when you have 2M or 20M lines of code floating around? Is every engineer expected to know enough to fix (or at least patch) any issue at 3 am?
    - mirceal 8y ago
      If you have 20M lines of code you hopefully have more than 1 team and you also hopefully have more than one service w/ the right interfaces/apis between them. As unrealistic as it sound, yes, if you're oncall you need to be able to understand the problem and fix it/mitigate it at 3am. This opens another can of worms around what is worth of a 3am page and how development, deployment and monitoring should be done but if you wake me up I should be empowered to do something about it
- hitekker 8y ago
  For those looking for a deeper look into the subject (and are not self-deceiving about human nature in groups) I heartily recommend https://en.wikipedia.org/wiki/Diffusion_of_responsibility https://en.wikipedia.org/wiki/Diffusion_of_responsibility
blablabla123 8y ago
That's the beauty of code review, it gets also checked for maintainability and whether it's a code style everybody accepts. It's also possible without code review but that requires much more things to be in place. Nothing is more frustrating than a single person pushing code that the other devs don't agree on and do have to fix/maintain actually.
- mirceal 8y ago
  yeah. the 10x-er usually play the role of wrecking havoc and after that the 0.1x-ers usually clean it up and stabilize it. If you're in that situation you need to get to greener pasture after you've put a reasonable amount of effort into explaining why this is bad + trying to raise awareness
  - blablabla123 8y ago
    Not sure if this matches my definition of 10x-er ;) No, but there is certainly some truth to it, those who routinely push a lot of code tend to be less stringent on following best practices. I think it's smart to keep changesets small but efficient without being neither too pedantic nor too sloppy. After all coding should still be a fun activity, even with all these crazy processes in place...
xsmasher 8y ago
I prefer the term SME (Subject Matter Expert) over owner.

breischl 8y ago

Some people have claimed that in my organization. I think that can work for library code, and particularly libraries that are used in many different places. But once you're talking about a service, or code that is only used by one service, then you need to have an owner (or a team of owners). If you still think there's no owner, then ask yourself who is going to get woken up at 2AM when it breaks, and that's your owner.

mirceal 8y ago
the team owns the code. the whole team. whoever is oncall gets to wake up at 3am if there is an issue.
- breischl 8y ago
  That works OK-ish for small organizations. When you have 1000 engineers, or even 100, it is no longer feasible to have a single on-caller who can keep up with changes enough to debug every system, much less the multiple on-callers you need in order to have an on-call rotation. IME even in small organizations (<20 engineers) it's very easy to end up not knowing enough to debug everything, and your on-caller basically becomes a smart router. ie, they can debug enough to figure out that it's a DB problem, and then wake up the DB guy. This becomes really annoying for the on-caller, so there's an impetus to have more focused paging groups, and now you're back to having owners for services.
  - mirceal 8y ago
    nope. you need to know how the thing that you're responsible for works. no exceptions. what you can have is an interface to another service/team that represents the boundary of your service. When shit breaks and you isolate the breakage to this dependency you wake them up (preferably you detect and you raise this automatically). bonus point if you thought about this as you were building your stuff and your service can work in degraded mode while the thing is solved. owners for services if okay as long as owner == team. if owner == individual you're doomed + people owning critical things will hate you and their job.
    - breischl 8y ago
      >owners for services if okay This is pretty much the exact opposite of your assertion at the beginning of this thread, to wit: >once you submit the code for review and it passes and gets merged everybody owns the code. Everybody. Anyway, this last comment I agree with entirely, and is pretty much what I've been saying all along. So I'm glad we can agree. >you need to know how the thing that you're responsible for works Agree with this as well, but a critical point is that "the thing you're responsible for" may be subset of "everything" in your organization. Maybe even a relatively tiny subset, in a large organization.
      - mirceal 8y ago
        yes. everybody in the team. i sure hope there aren't places out there where you have thousands of people each responsible for millions of lines of code. my point was that you should not have individual code ownership and individual gatekeepers. I can see how that might be misinterpreted.
- pmiller2 8y ago
  What happens when you have 2M or 20M lines of code floating around? Is every engineer expected to know enough to fix (or at least patch) any issue at 3 am?
  - mirceal 8y ago
    If you have 20M lines of code you hopefully have more than 1 team and you also hopefully have more than one service w/ the right interfaces/apis between them. As unrealistic as it sound, yes, if you're oncall you need to be able to understand the problem and fix it/mitigate it at 3am. This opens another can of worms around what is worth of a 3am page and how development, deployment and monitoring should be done but if you wake me up I should be empowered to do something about it
hitekker 8y ago
For those looking for a deeper look into the subject (and are not self-deceiving about human nature in groups) I heartily recommend https://en.wikipedia.org/wiki/Diffusion_of_responsibility https://en.wikipedia.org/wiki/Diffusion_of_responsibility

blablabla123 8y ago

That's the beauty of code review, it gets also checked for maintainability and whether it's a code style everybody accepts. It's also possible without code review but that requires much more things to be in place. Nothing is more frustrating than a single person pushing code that the other devs don't agree on and do have to fix/maintain actually.

mirceal 8y ago
yeah. the 10x-er usually play the role of wrecking havoc and after that the 0.1x-ers usually clean it up and stabilize it. If you're in that situation you need to get to greener pasture after you've put a reasonable amount of effort into explaining why this is bad + trying to raise awareness
- blablabla123 8y ago
  Not sure if this matches my definition of 10x-er ;) No, but there is certainly some truth to it, those who routinely push a lot of code tend to be less stringent on following best practices. I think it's smart to keep changesets small but efficient without being neither too pedantic nor too sloppy. After all coding should still be a fun activity, even with all these crazy processes in place...

xsmasher 8y ago

I prefer the term SME (Subject Matter Expert) over owner.