Comment by throwawaaarrgh | Hacker News Reader

Comment by throwawaaarrgh | Hacker News Reader

Parent Full thread

Let's be clear, then: there is a business problem, organizational problem, and communication problem, all of which is now dictating the software architecture.

If we're saying we have to do Conway's Law, we're admitting it's because we don't want to solve the above problems. If we say we don't want to follow Conway's Law, it means we have to deal with the above problems.

These problems are not insurmountable. But someone "in charge" does have to give a shit about them and decide the company is going to directly address them. And it's not just in service of architecture for its own sake; it's in service of a product being built better, so the customers and employees can be happier, which can then drive profits.

You can always get profits another way - be a monopoly, exploit a market flaw, lie, cheat, steal, pressure your employees, cut costs until the product bleeds, offshore, exploit tax havens, or all of the above and more. But happy customers and employees is more sustainable. Not as much growth, but the company will still be around in 20 years without having to fight for survival.

It's not a "business problem, organizational problem, and communication problem". (Or not always: caveat at the bottom.)

Conway's Law isn't a flaw, it's the correct way to engineer a product, whether the organization is dysfunctional or functional.

Humans working together on the same product need to communicate. The farther away they are, the more this communication becomes harder, fragile, and prone to misunderstandings.

Thus, the boundaries between their areas of responsibility must be manageable via whatever communication resources are available.

If two people are working side-by-side and constantly aware of each other's work, they can easily cooperate on a single imperative function with no isolation whatsoever.

If they're totally separate teams that normally communicate via emails and need to schedule a meeting a week in advance, then you need to have iron-clad API contracts between their codebases to enable them to work in peace. The other option is to get the teams closer, but that may simply not be possible past a certain scale - you just can't get 100 engineers to know what everybody else is doing.

Sure, if you have a team of 8 people and they have no idea what each other is doing because there are 16 middle managers wasting their time? Then yeah, you absolutely have a business problem, and Conway's Law will be a bandaid over it - you'll split the product into 8 libraries or 8 microservices, wasting a bunch of resources but keeping your engineers sane. But if you solve the problem and put the 8 engineers in a shared room so they can collaborate efficiently, and get rid of the no-longer-necessary boundaries, you're still following Conway's Law.

> Conway's Law isn't a flaw, it's the correct way to engineer a product

Conway's Law is not a way to engineer product. It is an emergent property of a system, called homomorphism.

It's flaw in most systems because an organization's natural structure leads to flaws in the system. (https://www.atlassian.com/blog/teamwork/what-is-conways-law-...)

The thing is, it's not written in blood. You don't have to reorg to redefine your architecture. You don't have to design an ironclad API, or work on an "imperative function" between people sitting in the same room. In fact, there may not be an organizational principle that will give you a good architecture.

Want evidence? Open Source software. People sitting halfway around the world making software that has eaten the entire planet. Some of the contributors have commercial interest, but they don't get to dictate the architecture. And hey, how about that, the software gets made well anyway, even though the communication structure is often just one global mailing list. "The org structure" doesn't define the architecture because it would become random. Instead, the software's architecture is defined, and then people go out of their way to figure out how to make it. It is the opposite of Conway's Law. Yet it has been working for over 30 years.

Conway's Law is a flaw in human ingenuity, like a bias. We have many biases. Bias is an emergent property that, if unchecked, leads to bad outcomes. But we are capable of rising above them, if we try. The result is better if we do.

Re your point on OSS being architected first, then the org shapes itself around it, a decent counterexample is the development of git.

https://www.linux.com/news/10-years-git-interview-git-creato...

Written specifically to match the politics of Linux kernel development, since there wasn’t an open source alternative that could do so already (paraphrasing the interview)

Git is a great example of terrible design; Linus has said this repeatedly (and it's in the name).

Most successful open source software is simply designed however one person thought it made sense. Often this design ends up being reworked into a new major version, but again, in most open source projects the goal is just better design without deference to communication structure.

You see phenomena which are at least related to Conway's Law across organizations more broadly which is why you see companies switching back and forth between matrix organizations and functional organizations, independent product teams and cross-product orgs, and various variants of those and others.

So, for example, you can have more generalist organizations that hopefully consider the needs of the portfolio as a whole and can sell the portfolio appropriately with fewer product fiefdoms. But you probably give up some of the advantages of a specialist organization that's really expert in and focused on making one product succeed in ways that are specific to that product. Of course, companies can and do create various overlay organizations that can work to greater or lesser degrees. But there are always tradeoffs. In my career, I don't think I've ever seen the right organization--only better and worse ones for the current circumstances.

If you want to stand on the upstairs balcony, you can be that asshole who parkours up the opposite building and then leaps across onto the balcony.

Or you could just use your keys and walk upstairs like a regular person.

Many things can be accomplished the hard way. A lot fewer people are impressed by it than you think. Most of the ones who are are immature and loud, so you mistake that for numbers.

In a very large organization, while you’re carrying off the project by force of will, someone in another division is using less energy to accomplish better outcomes, and gets promoted over you and becomes your boss. You won the battle and lost the war.

Reply on news.ycombinator.com