Connect them with clear APIs that don't have to change all that often, and you can build pretty big things.
I imagine this is doable with hardware too
Connect them with clear APIs that don't have to change all that often, and you can build pretty big things.
I imagine this is doable with hardware too
In particular it’s difficult to train new people to take up on-call duties if they cannot sit in the corner of the room and try either the same things you’re trying or their own pet theories without taking your attention or interfering with your tests. They need to be able to hear the repro steps and spool up their own snapshot in a similar state. That scales. Gatekeepers do not. Discoverability is necessary but insufficient to achieve this. There’s more to it but the foundation is discoverability and reproduceability.
(It also usually involves some quite proactive learning of the form of finding the specialist in some part of the system and sitting next to them and going "explain to me how this part works", and then repeating more or less indefinitely)
Emphasis on clear. It's a challenging endeavor to properly draw and enforce these service boundaries.
This is one of the things monorepos help in some ways (by making it easier to change two systems) and break in some ways (as you now get less annoyed by the split between systems being in the wrong place)
In a system that is the composition of 30-300 different functional units, nobody will be close to any one part unless they’re the bus number for it. So each piece needs to be dead obvious so you can worry about the consequences of composing them. At the end of the day it’s Kernighan’s Law but rephrased so as not to ignore Conway or Brooks.