2 ms·

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 represen

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.