The Only Unbreakable Law

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

Also known as the only unbreakable law ( ▶ this video ), a fact which feels deeply depressing when you dig into it.

“Time” is the answer almost always. Standards evolve over time, as do the languages and frameworks. Old code is rarely rewritten, so you end up with layers of code like geological strata recording the history of the developer landscape. There’s a more complicated aspect of “Conway’s law, but over time ” that’s hard to explain in a comment. And anyway, Casey Muratori did it better: ▶ this video

The Linux kernel is the perfect example for my case. We should absolutely create a new OS to replace Linux. Just an example, and not only my opinion, rather a widespread one: There is no need for multiple mechanisms of interprocess communication, they only add to the complexity. Conway’s Law[1]: > Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. In his famous lecture [2], Casey Muratori makes the case that Conway’s Law applies over time too, meaning there is not a single organization, but multiple versions of the organization over time, and all of them end up adding more design (decisions) to the product. The best example, which he gives, is the 5 different UIs to change the sound level in Windows. Rewrites to old (10 years old as I said) software reset the age of the software to zero and very often drastically simplify both the design and the codebase. I’m not telling you to rewrite your 3 yo product. 1: link 2: ▶ this video

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.

You may find this video interesting, ▶ this video It's about Conway's Law. I think that's worth looking into based on your question. You can look it up on Wikipedia if you don't wanna watch the video and would rather read about it.

You ship your org chart. Worse than that, you also ship your org chart changes over time : ▶ this video A company with 100k employees will ship crap just by default. And Google is a shining example of that.

Yes, you can! You can even tell when the organization was changed, since many complex systems are upgraded over time. The example I like best is the Windows volume control(s), as pointed out by Casey Muratori ( ▶ this video ).

> 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

Casey discusses a couple of the laws (i.e. Amdahl's law, Conway's law) in his "The Only Unbreakable Law" video: ▶ this video

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

I remember seeing a great explanation of Conway's Law by Casey Muratori: ▶ this video (The whole talk is good but Conway-s law starts at 11:37)

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.

desktop environments (from Windows to iOS, including OSX, macOS, KDE, Gnome and everything in between) sort of already do this. they provide services and they provide apps/programs that require those services. what they don't provide is interchangeability of programs from different environments. probably the closest thing is the freedesktop.org semi-standards, but there's not much compatibiltiy or interoperability between KDE and Gnome stack. (KDE's Plasma needs all the usual K-things and Gnome's thing needs, well, I don't know what it needs, but it does almost nothing but needs a bunch of things to do that :D Xfce sort of piggybacks on Gnome, but also uses a lot of their own shit, but at least Xfce is great.) basically this is due to Conway's law: ▶ this video because there's no counteracting force that's pushing back to make things use a standard :/

Not even to mention the impact Conway's Law suggests! As a company grows in number of specialized teams, you'd expect to see magnifying difficulty in having efficient communication, eventually impacting what the product looks like (or at least, how robust the code is and how easy it is to augment). Seems like it could be a bad feedback loop - code got more complex indirectly because of number of teams, so naturally you hire more people to maintain the same output. See this video by Casey M. ▶ this video

> the major foot-gun that got a lot of places in trouble was the premature move to microservices I sometimes wonder if the move to microservices isn't just a weird consequence of Conway's law in reverse: make a department of each developer, let them have their thing. (See also this amazing video about Conway's law: ▶ this video )

Interestingly this talk by Casey Muratori [1] makes a reasonable rhetorical case that Amdahl’s law (about process parallelization), Brooks’ law (about team network communication) and Conway’s Law (about how organization communication shapes software structure) might all be variants on the same basic principle of trade off between parallelizable and unparallelizable work… [1] ▶ this video

Great article. I also suggest watching Casey M. recent video[0] about Conways Law. How organization in your company determines what you can/will do and how organization of your code follows the same principles. Starting with just the handlers and introducing layers as you make sure its time is great way. [0] ▶ this video

Funny, just watched Casey Muratori cover the same topic on his channel: ▶ this video I thought he covered it well. He considered the temporal aspect of orgs, which meant that software, over the years not only mimic the org, but every org that had ever been there over time. edit: oh, and unexpectedly, he's still around and on twitter. link

A good illustration of The One Unbreakable Law ▶ this video (Conway's Law, but do watch the talk for more context)