What I've found is that any large refactoring project that works against Conway's law will fail, until the plan adjusts to the org structure. This can be very explicit, in that one group will refuse to support it, or latent, in which teams won't use the new project until it is reworked to support them.
The sad thing is that pretty much every large refactor that I've seen has started as an explicit attempt to remove the 'smell' of the software architecture being built off of the org structure.
All Conway’s Law means is that to build a system (from new components, anyway) that work really well together it is very helpful for the builders of those new components to communicate with each other during the process.
This is a fine heuristic, but it can be interpreted in different ways as you see fit. For instance, since I advocate for professional testing (rather than amateur testing that Agilists prefer) I say, by Conway’s Law, that testers should be gathered together in one team, rather than scattered around in little Scrum teams. Testers benefit more by working together than they do by hanging around developers, since only coding testers really can deeply understand the devs and the code, and when they try they simply become junior developers and lose all the critical distance that makes independent testing effective.
By Conway’s Law, the “Whole Team” approach really just coopts testing and isolates testers (like being the only sober guy at a party), and puts the tester under pressure to get along instead of critique the product.
Fowler poo poohs the idea of independent testing in his article, but he is not a professional tester and I think he hasn’t thought this through. The couple of times I met him he was friendly and listened well, though.
> it is very helpful for the builders of those new components to communicate with each other during the process.
IMHO, it's about communication and incentive structures. Each person is naturally going to optimize for the incentives of their local team, so the job of the organizational-designer is to align these incentive structures across teams.
> since I advocate for professional testing (rather than amateur testing that Agilists prefer) ... Testers benefit more by working together than they do by hanging around developers, since only coding testers really can deeply understand the devs and the code, and when they try they simply become junior developers and lose all the critical distance that makes independent testing effective.
This is really interesting to me, since I largely believe the opposite: Engineers should be writing their own tests, because otherwise they won't be incentivized to write good, clean, maintainable, testable code.
Can you share more about your take on this? Sounds like you've probably had similar conversations before — any particular case studies or data you like to lean on?
Note that Conway's law states that systems will be structured according to how humans communicate. Often, for dev teams, that aligns with how the APIs interact, but for, eg, testing teams, doc teams, devops, etc, that communication might be all the non-functional stuff that doesn't have to be in code per se but is still valid communication, and will still drive org structure per Conway.
So I think your idea is still compatible with Conway.
I don't view Conway's law as casting as negative a tinge as most seem to. It makes sense that responsibilities be split roughly along the same lines as they are in physical organizations, especially in orgs where software is not a hermetic black box but represents business processes. Groups probably have need to twiddle with the representations, and drawing the same lines of responsibility as permissions makes a lot of sense there.
As a contrived and probably nonsensical example: if you have a widget factory, and you have two departments, sales and fulfillment, it's often better to represent a sales order as "An immutable list of items sold and prices, and a mutable list of references to fulfillments that satisfied that order" over "a list of items sold, prices, and how many have been delivered", with a separate object that is the fulfillment.
Those are different departments, they move at different rates, and edit permissions for each should be limited to their respective orgs.
I remember seeing a great explanation of Conway's Law by Casey Muratori: https://youtu.be/5IUj1EZwpJY?t=697 (The whole talk is good but Conway-s law starts at 11:37)
> Gradually it has become clear to me what every great philosophy has been: namely, the personal confession of its author and a kind of involuntary and unconscious memoir; also that the moral (or immoral) intentions in every philosophy constituted the real germ of life from which the whole plant has grown.
I originally came upon this quote in the context of a comparison of personality theories (Dave Kelly, Ptypes).
OK so I just read the wikipedia page on that and I don't understand the origin of your uncertainty. What is apparent and certain is that you know it better than I do and I'm interested to understand your thinking.
That and it's dope that we're only two branches offshoot from software architecture.
Probably. It is possible to think and write in another's mode. But it's difficult to do consistently, and it certainly isn't satisfying to the person doing so.
Organizations are models of reality, with their communication structures reflecting past experiences and realities. As reality changes, these models may become outdated. However, organizations often invest more resources in maintaining the existing model instead of adapting to new realities. Conway's Law highlights this inertia by emphasizing the relationship between an organization's communication structure and the systems it designs.
The natural evolution of a social model from tool to symbiont to parasite.
We put a horizontal team through a silo’d org structure with great success. The team is Release Engineering in all but name and we used the project of “make releases faster” to send a shock wave back up the org in order to bring a once-deliberately segregated product / org structure much closer together. The goal was to do so in the name of speed and flexibility.
As with any shock wave, the healing energy dissipated the further it travelled. We don’t expect to be able to effect complete removal of product silos all the way up one end of the org by applying change from the release process from all the way at the other end. However, the wave propagated quite a long way. We only have 10^1.9 engineers which helped make the changes tractable and was also the basis for wanting to move to a much faster org structure.
In short, we had a micro teams and microservices structure that would suit a team of 8,000 when in reality there are only 80 of us (series B, 9 digit valuation) so we drilled a hole in the side of the complicated old ship and got everyone into the same life/speedboat instead.
a hazard of the practice of listing all previous related articles like this might suggest the content of the newly-posted article is likely to be of little value
What this means to me is that you can't change your organisation with software alone. And I believe it was Martin Fowler who said to me "If you can't change your organisation, you should change your organisation".
The same, at least in the remote-first org that I'm in
Remote still has teams and department with reporting lines and clusters of incentives, responsibility, and who communicates how often with whom and in what manner.
>Everyone's favorite law to cite but I rarely see a lot of examples
If you're looking for experimental validation of Conway's Law, the best work I'm aware of was done by Microsoft Research analyzing the Windows Vista development effort[0]. They found that organizational measures (eg. how high up in the org structure do you have to go to find every developer who contributed code to a particular DLL, etc.) were significantly better predictors of post-release code quality than traditional metrics like churn, complexity, coverage,
dependencies, or pre-release bug counts.
If your company builds software, there's a tax to pay if the code architecture and human architecture are poorly aligned. The bigger that misalignment, the bigger the tax. Conway's Law misalignment is like technical debt in the sense that it's always there at some level, and there are times when it's important to reduce the cost and there are times when it's better to accept the cost and focus on other taxes/debts.
The best quantitative work I'm aware of on open source vs non open source (really bazaar vs corporate) architectures as it pertains to Conway's Law is [0]. The paper isn't specifically about Linux, but I think the results of that paper would argue Linus himself makes Linux a bit of a hybrid of the two models they studied.
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.
Literally every company I've worked for has had an architecture defined by team boundaries. When new teams emerge, the architecture changes. It's comically accurate.
Places that don’t follow this pattern struggle, and struggle, until someone finally decides to change the project whether management likes it or not.
Functionality that is split across organizational boundaries is very slow to deploy and difficult to get right. So even if someone doesn’t fix the structure, the number of features that fall within team boundaries quickly multiplies while those that aren’t so lucky grow more slowly.
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.
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.
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.
I mean...it's self-evident if you've worked in any large software department. Well, with one caveat; there is the inverse, where a company's organization doesn't reflect its software, and there almost nothing gets done, and what does get done does so at a global pace. I've seen that too (oftentimes you get that in the startup that has grown too quickly; the only way anything can get done at all are the people who have been there since it was 50 people, since they know who to talk to).
Edit: as dang posted the original article ("a principle with much broader utility than in software engineering"), I guess another example is the "county sheriff" and their occasionally newsworthy antics in the States. Reading about them from a country where counties are not a thing (nor do we suffer from their lack) makes me think the politicisation of the sheriff's office may be a less software-oriented example of Conway's law.
Hmm, I’m not sure. I think that example would need to be fleshed out a bit (at least, I don’t see it, but then I live in the US so maybe I’m missing the forest for the trees).
Conway’s law is about the structure of the thing being built mimicking the organizational layout of the people building it.
The county sheriff is just the sheriff attached to that unit of administration. It seems more like if Conway’s law was the observation that shape of the management tends to match that of the org chart. It is not really a correlation so much as a tautology.
Fleshing out the example: as far as my experience goes, there is no governmental function that would be more effectively handled at a "county" level. Yet in the States the unit of administration exists, so law enforcement solutions incorporate (heh) county sheriffs departments (even when these are composed of personnel with no real law enforcement background).
I'd recommend reading the book Team Topologies [1] - it was well-written and gave me some new ideas for how teams can interact. And it's deeply founded on Conway's Law, including featuring a concept called the reverse Conway maneuver [2].
(Note that the book and the reverse Conway maneuver is also mentioned in the friendly article)
Is it accurate to say that as an open source program, LLVM doesn’t really have a rigid communication structure, and it also has instead a framework that can be extended to an arbitrary number of passes?
The sad thing is that pretty much every large refactor that I've seen has started as an explicit attempt to remove the 'smell' of the software architecture being built off of the org structure.