The Most Powerful Law in Software | Hacker News Reader

The Most Powerful Law in Software

registerspill.thorstenball.com

50 pointsingve16 comments

Org structure and software structure do affect each other, but the effect is bidirectional and isn't as strong as to make it a "law". Read Conway's original paper and you'll realize the nuanced point he was making. Like much software dogma these days (Mutability is the root of all evil, premature optimization is the root of all evil, DRY, YAGNI, SOLID, Conway's Law, etc), there is some interesting thoughts there, but they've become blunt weapons to bludgeon people, and so when people invoke them, I now tend to see such people in a poor light. Sure lets discuss how to organize teams and cross-team structures and come up with organizational mechanisms to solve some problems, but if you tell me you're doing a "reverse conway maneuver" or "lets not ship the org", I really doubt your ability to develop complex software.

I largely agree, but one nitpick is that “let’s not ship the org” is really just a polite way of saying someone is missing the forest for the trees and not making the right overall choice for the system/product.

1. Management almost always is a hygiene factor - good management is necessary but not at all sufficient, bad management will screw everything up. In general it is safer to have minimal management and rotate them out quickly - probably just have HR with budgets.

2. Good design is fairly simple if the right constraints are known. what the customer needs, hiw the market works. Org charts are an artificial constraint that if you do not allow other constraints to impact designers (ie coders) then that's the constraint they work to. In short if you let coders talk to users regularly and to the business daily things work out waaaay better than having them work to a PMs vague desires

Very good points. Letting the coders talk to the users is unfortunately rare and probably undesirable for a lot of larger organizations.

I'm concerned that the progress of LLMs will enable more bureaucratic and BS in corporate cultures.

OpenAI's CEO tweeted [0] that people using ChatGPT to compose a polite, business grade email from bullet points, and then the receivers decode it into bullet points. If this is the future, I guess we may see more verbose, a little bit cryptic sentences in emails (just like compiled code is getting more cryptic for human). And we already have lots of meetings that most people think meaningless. Now the records of meetings are automatically transcribed, stored in company's knowledge base, and retrieved by simple chats with ChatGPT. It gives a false impression of productivity, and encourages more and more meetings!

I think we need to refactor the organization/culture first, or we'll engage more complicated business ritual and pay small amount to OpenAI every time we need to reduce the BS that we've created unnecessarily.

[0] https://twitter.com/sama/status/1631394688384270336?lang=en

I don't really understand the practical value of internalizing Conway's Law. Presumably you are designing your engineering organization to be as productive and efficient as possible? If your product reflects your org structure, why does that matter?

Put bluntly, does Conway's Law give me anything actionable to consider when I'm building an engineering org?

I thought the article kinds of explains it already -- silod teams will then create silo'd features (that won't play together well, won't look consistent, won't feel consistent). Thus to create a truly integrated product you need have cross-team organizational communication structures.

This is the key question for me too. TFA gives some hints, like,

- can we use this to empower a team to really focus on a key component, removing other concerns from them?

- how do we ensure consistent quality across the user experience, if different teams own different parts?

But I don’t yet have a clear thesis, or even a collection of key tradeoffs to consider when thinking about how the org design will impact the product.

A decision that will need to be made is how projects are run. An engineering-driven org might be broken up along systems. However, cross-cutting projects will suffer a communication barrier. You could instead align teams around initiatives rather than systems to execute, but then tech debt will increase in those systems as people forget their original intended purposes in favor if getting the project done.

> Put bluntly, does Conway's Law give me anything actionable to consider when I'm building an engineering org?

Because your architecture will match your communications structure, it means that if you want your system to work a certain way, you’ll want to make your org chart match it. If the system architecture is the thing you want, and the org chart is what you can control, it follows that you should mold your organization to match your desired architecture.

Conway’s law is a law, not an anti-pattern. Resisting it is a bad idea, instead learn and understand it, and plan around it.

It may have been an interesting observation in 1968 but it's "not even wrong" today. IMO there is tons of useless friction in trying /not/ to ship the org chart. I've observed orgs where the software boundaries/APIs line up with organizational ones, and others where they have nothing to do with one another. The latter require years of meetings and proofs of concept before half-shipping products nobody wants. The former just ship software relatively cheaply, and if it's the wrong thing it's cheap enough to change it.

No other industry tries to avoid shipping their org chart. GE's space division does not consult with the oven division before it builds something.

well, software is 5th way of storing knowledge (see Philip Armour [1]) - i.e. it is "canned"/"frozen" communication, but with automatic (machine) -interpretability - which uncans/unfreezees pieces when using them then freezes again.

so i guess, anything related to Communication, applies here. And if the machine interpretation is 1000 times faster/stronger/stricter, then multiply by 1000 too..

[1] https://www.amazon.com/Laws-Software-Process-Production-Mana...

Good write up. Conway’s law is super important. I work at a FAANG and our org’s most senior leader had that point too.

Why they got to assume their reader is a “man” at the end though?

> Why they got to assume their reader is a “man” at the end though?

"Man" can in many cases refer to more things than just "men". Like mankind, or the typical surfer/stoner-usage of "man", which refers to any gender/non-gender, which is the case in this article. Just like "dude" can mean more than just "you of male gender".

For posterity, the article ends with the following:

> Pure thought-stuff, indeed, man.

It's just an expression. Could be replaced with 'dude' or w/e. Where I'm from (we speak spanish) people literally say "that's dope man" or "wtf dude" and the last term is said in english ("que chucha man", "que verga paso dude"). Girls say 'man' (in english) to each other. We could get into all the woke stuff here but I don't think it adds anything of value to the conversation.

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. (https://youtu.be/5IUj1EZwpJY, 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 also adds another interesting consideration, which is that Conway’s Law persists in long-lived projects; because yesteryear’s org chart reproduced itself in the software architecture and today’s development efforts have to engage with the existing architecture, you are not just constrained by your org chart, but rather (in some sense) constrained by every org chart you’ve ever had.

The main point of Conway’s Law is that when you are making your org chart, you are also choosing the destiny of your product, in ways you might not realize. Some actionable steps from this point might be “if you want a unified consistent UI, you need a single UI team with responsibility for all parts of the UI”, or “if you want good integrated graphics in your CPU, you can’t have separate GPU and CPU departments”.

* There are examples showing this is an unusually strong effect. Microsoft had a graphics and an audio team; for graphics split into a subteam for 2D and a different subteam for 3D, for audio they split into a subteam for music and a different subteam for sound effects. As a result you get these APIs in the final code: Direct2D, Direct3D, DirectMusic, and DirectSound. The Music and Sound subteams got combined; DirectMusic and DirectSound got deprecated and merged into XAudio.

Reply on news.ycombinator.com