3 ms·

For software, the easiest way to design for this is to keep systems small enough that fitting it in your head is relatively feasible in a reasonable time for a

For software, the easiest way to design for this is to keep systems small enough that fitting it in your head is relatively feasible in a reasonable time for a competent engineer. 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

unreal6 1y ago
> Connect them with clear APIs that don't have to change all that often, and you can build pretty big things. Emphasis on clear. It's a challenging endeavor to properly draw and enforce these service boundaries.
- hinkley 1y ago
  Occasionally I make an analogy to stage acting or opera. In order for the people in the medium priced seats to see the action on the stage, all the actors have to over-emote to make everything that is happening dreadfully obvious. 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.
- procaryote 1y ago
  Definitely! My metric is "how often do I need to change two systems at once". 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)
hinkley 1y ago
My yard stick is discoverability. If you don’t touch things for a while they get fuzzy, and someone might have refactored it. So you need to be able to familiarize yourself with bits of the code you haven’t looked at recently. Helps with code reviews, onboarding, and production outages. 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.
rcxdude 1y ago
In my experience (and I generally have found myself in the position of 'person that has the system in their head'), it's not necessarily about size but about being able to sit down and work with the system. It's not just about having the theory but also having the time actually working with the system and learning how things act in practice, which is a kinda weird mix between being a senior role with a high-level view of the system and a theoretically quite junior role of more or less technician. (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)

unreal6 1y ago

> Connect them with clear APIs that don't have to change all that often, and you can build pretty big things. Emphasis on clear. It's a challenging endeavor to properly draw and enforce these service boundaries.

hinkley 1y ago
Occasionally I make an analogy to stage acting or opera. In order for the people in the medium priced seats to see the action on the stage, all the actors have to over-emote to make everything that is happening dreadfully obvious. 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.
procaryote 1y ago
Definitely! My metric is "how often do I need to change two systems at once". 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)

hinkley 1y ago

My yard stick is discoverability. If you don’t touch things for a while they get fuzzy, and someone might have refactored it. So you need to be able to familiarize yourself with bits of the code you haven’t looked at recently. Helps with code reviews, onboarding, and production outages. 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.

rcxdude 1y ago

In my experience (and I generally have found myself in the position of 'person that has the system in their head'), it's not necessarily about size but about being able to sit down and work with the system. It's not just about having the theory but also having the time actually working with the system and learning how things act in practice, which is a kinda weird mix between being a senior role with a high-level view of the system and a theoretically quite junior role of more or less technician. (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)