4 ms·

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. Bu

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

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