4 ms·

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 c

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.

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.