A-TIER resource
Conway's law — Casey Muratori on the one unbreakable rule, now for agents
100k ft — What is this?
Conway's law — Casey Muratori on the one unbreakable rule, now for agents
50k ft — Why care?
Casey Muratori argues Conway's law is software's only real law: once you split work among workers (people or agents) whose communication is slower than their internal compute, design iteration across that boundary is locked in as slower. 'Products look like the org chart' is a consequence, not the law itself.
10k ft — Key takeaways
• Cross-boundary changes will always be slower than internal ones
• Put boundaries where you expect the least design iteration
• Your agent decomposition will shape the architecture you get
5k ft — Tools & techniques
(no tools tagged)
work partitioning
1k ft — Deep-dive / try it
The only unbreakable law in software engineering
Casey Muratori (Video Game Dev & Creator): What is the only unbreakable law in software engineering? The only thing I've seen that feels like a real law to me is the thing I cover in this lecture, which is Conway's law.
And it is that if you would like to organize a series, like a set of people to work on something, or in the modern parlance, let's say agents, if you need to partition a problem into a set of workers in this way where the communication between those workers is slower than their own internal computation ability, when you start to tackle a problem, in order to get the benefits of that parallelization, you will have to make decisions about who is working on what.
Once you've made that decision, you have now locked in the fact…
Transcript excerpt
What is the only unbreakable law in software engineering? The only thing I've seen that feels like a real law to me is the thing I cover in this lecture, which is Conway's law. And it is that if you would like to organize a series, like a set of people to work on something, or in the modern parlance, let's say agents, if you need to partition a problem into a set of workers in this way, where the communication between those workers is slower than their own internal computation ability. When you start to tackle a problem, in order to get the benefits of that parallelization, you will have to make decisions about who is working on what. Once you've made that decision, you have now locked in the fact that the iteration on the design will be slower across that boundary than it is interior to either of the two parts. One way the rule is pithily stated is products look like the org chart, right? But that's not exactly what it says, but that's a downstream consequence. And boy, do you ever see it in the real world.