Molly Rocket
12 HN recommenders · recommended in 14 months, 2022–2026
53:25 · 487K views · Mar 16, 2022
Casey Muratori's lecture, originally given at the Technical University of Madrid, arguing that Conway's Law is the only viable candidate for a true law of software architecture. He explains how software mimics the organization over time, using examples like Windows' multiple volume controls.
HN treats it as the definitive explanation of Conway's Law and links it in almost any thread about org structure shaping software.
20 comments from Hacker News
Casey Muratori has an excellent lecture on this same topic, which draws many of the same conclusions as this article but goes into more depth on why it happens and what it means to you in a practical sense. ( this video , skip to 15:30 as the beginning is about setting up the idea of software laws, discussing other candidates for strong software laws, and the history of the law.) The Cliffs notes if you don’t have time for 45 minutes of video: Conway’s Law is pithily stated as “org charts reproduce themselves in the product”, or more comprehensibly as “the software architecture will resemble the org chart of the company producing it”*. The mechanism of this effect is communication bandwidth. Communicating inside a team is high bandwidth; between teams is low bandwidth and multiple lossy hops, with the problem getting worse the further teams are away in the org chart. What this means for you is that when you set down an org chart (which you have to do at least a little bit before even getting started), or when you change an org chart, you are eliminating any potential architectures that don’t look like that org chart. There If you split your teams into frontend and backend, you are ruling out potential architectures that would mix or closely intertwine the two. Any architecture like that would require the two teams to work together intimately, taking steps in tandem, which they cannot do because the low bandwidth cross-team communication cannot support it. Later in the video he a
Some great examples in "Conway's Nightmare" this video My favorite from memory is that Windows now has five completely different volume control UIs, each of which can be traced directly to distinct product teams and their organizational dynamics across time. This video makes goes futher and says that the evidence for Conway's law is not only strong but has yet to be disproven; the closest we can get to a fundamental law in computer science. Given that software is always created for a social purpose (there are some users or beneficiaries of the technology), it's sort of a tautology that social dynamics are going to strongly influence design.
If you want to dig into Conway's law and its implications, I can't recommend this video essay by Casey Muratori enough: this video Fair warning though, you'll lose all hope that companies like Microsoft will ever manage to produce anything that they don't then ruin.
> What resources do you recommend folks at my level look into? I'd argue that your best bet for learning is starting a project that drives you, then throwing that project away and starting it over again but try to make the code simpler. This way you can hone into what abstraction is actually necessary to solve your problem. I strongly recommend ignoring design patterns and instead honing in on what the essential data flow is in your problem space. Most design patterns will bloat your code base and, thus, slow both your program and your programming velocity down. As far as programming design and architecture goes, the best talks I have found come out of data orientated design talks. Casey Muratori has a number of talks well worth listening to[0][1][2]. I also enjoy Andrew Kelley's talk on Data Orientated Design specifically as it demonstrates DOD's power with actual numbers to back it up[3]. Tangent: I did my time with OOP design + trying to make my code 'clean' according to popular recommendations you'll see online. All of that time, I consider wasted because I focused too much on what the 'right' abstraction to use was, instead of solving my problem in the simplest way possible. I find now that often the best solution is the one that uses the least amount of abstraction and indirection. (E.g. One big function can be a lot easier to maintain than multiple little functions, you just have to develop a taste for when a function should be split up and why). (If you must have a pa
I found this video [0] recently by Casey Muratori that really helped me understand why Windows is the way that it is. It's about Conway's law in software development and software architecture, but he explains it with anecdotes about Windows, like how vendor communication challenges lead to 4 different volume sliders. I would pass on an expensive heavy-partnership Windows device. [0]: this video