Inverse Conway's Law; organizations are encouraged to create isolated, disconnected teams in order to benefit from modular maintainable code with clear and distinct interfaces.
If it is one thing that I have learned at a large software company it is the fact that Conway's Law is fundamentally true. Any software system is a mirror of the team setup and the interactions between the involved people. And many bugs are found in the interfaces/interactions between components of isolated teams.
However, this also means that as a software developer you are unable, or at least very constrained, in the ability to improve or refactor any complex legacy system. You are basically fighting uphill battles in such situations, because you are not in the authority to change/improve the organizational structure.
This also means that as programmers we may need to take more time and care to invest in human relationships and in our communication skills, as this could have an significant effect on code and product quality.
I believe so too, but it's not even that much a function of team structure. A proper design will have lots of places that are mostly self-contained at various levels of abstraction - more than people you have in your team. I believe work should be distributed among those boundaries, because it lets people agree on the interfaces and work mostly in isolation.
Also, most of the time, small self-contained units of code are trivial to fix if the original developer goes under the bus, because small means any half-decent developer should be able to read the code[0] and understand it, and self-contained means you're not afraid to change things because you can easily track how the effect of your changes propagates.
--
[0] - an activity that people often shy away from, or are afraid of. Can't for the love of God understand why.
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.
We have found that by changing our software/system architecture we have also inadvertently changed our organisation structure.
- Inverse Conway Law or just Roy's Law ;-)
Before we had four cross functional teams, working on a single application, everyone felt responsible for it, worked overtime to fix bugs etc, we had good communication between the teams.
But after we switched to microservices the teams became responsible for just a part of the system, their microservice(s). Whenever we had an outage, one team was left to fix it, the others just went home. They stopped talking to each other because they didn't share any code, no issues... they stopped having lunch together, some things got way worse in the organisation, all sparked by a 'simple' architectural change, moving to microservices.
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.
Why can't you decouple teams form each other with modularity and encapsulation? I never worked in a team, but I could imagine that teams just have some agreements about interfaces and then work independently on a single code base but in a different classes and packages.
Having autonomous teams is great for scaling and allowing everyone to go fast, without teams constantly blocking each other.
Having hundreds of engineers work in a single monolith in a single repo without any kind of (enforced) boundaries is a one way ticket to a big ball of mud. You need to invest heavily in tooling to make it work, and e.g. Google does so.
Having a network in between teams is a relatively easy way to enforce boundaries.
The problem with that approach is that as you scale up, it becomes hard to be sure you're isolated. And that lack of clarity in the human comprehension turns into technical ways in which it will turn out that you're not isolated after all, for instance my example of a base system library upgrade that one team does and breaks another team.
You can in theory fully isolate everything between teams, but without technical barriers preventing you from crossing, you will eventually cross.
Plus you have the problem that while full isolation will benefit your project and your company three to five years from now, violating the isolation benefits the company now. Every monolithic bit of software in the world could have been split, but there are real reasons why it wasn't, and they don't go away because someone observes that it could have been done a different way.
Isolated containers, by providing a technical barrier, allow the teams to be sure that they are both isolated from other teams breaking them, and breaking other teams, with things like library upgrades. It's a significant change.
It is productive to consider the difference in the Android world, but I would submit the isolation works in another dimension there, by virtue of the various apps being by necessity utterly isolated in Conway's Law terms. Within a single corporate entity there are many more temptations to get short-term wins by violating the barriers that theoretically should be there.
I think there's a connection to be made between Conway's law, domain driven design, and building silos within an organization to reduce communication overhead between teams. Teams and project ownership should be structured so that teams have what they need to work on their own, with as little dependency on others as possible. The same thing goes for the services they're writing: data transfer and ownership within the domain is okay but should be minimized outside of it.
This. This is so often overlooked. Getting your architecture to roughly align with your team structure can do wonders, even if there's only a hallway dividing people. When a small team can iterate and evolve a chunk of code independent of anyone outside the team, it really unshackles them.
There are obviously patterns for doing this in monoliths (or, say, mobile clients - another type of monolith), but at some point you are bound by the dependencies inherent in a single runtime.
because Conway’s law tells us that having an ops team is the surefire way to end up with a set of operational procedures/processes, tools and infrastructure whose complexity will in turn justify the existence of said ops team.
bwhahahaahaha
turn devs loose in production and you will soon realize stability is a good thing
Keep in mind that size doesn't necessarily equal complex. Where I have seen Conways law most clearly is with dysfunctional teams regardless of size.
I was on a team once where one of the senior people was such a jerk no one wanted to work with him. This led to him and the team carving out a piece of the system that he alone worked on and interfaced with the rest of the system through a single queue. This was certainly not the best design and added all sorts of unnecessary complexity.
Another team I was on had a person who was a good programmer and tended to blow off design meetings. The organization never rarely reprimanded this person. In turn it led to various APIs being built that were close, but always not quite right.
Big company examples abound. Contrast and Apple keynote to a Google one. Sometimes I wonder if the people presenting at the Google one even work at the same company.
Arguably, some level of modularity is good anyway and that's been the general trend. And a lot of software, perhaps especially large open source projects, are developed by a fairly distributed set of individuals and teams already.
That's why software organizations need to be modularized, just like code, so the small teams can work efficiently. But on the other hand, doing that just pushes complexity around. Instead of having a team chaos problem, you have an API and requirements chaos problem.
Very good point. Tying that back into the Conway's law angle on all of this...
I've been a couple levels up the chain at times in my career. When I've seen technical decisions at this level done well is when those people realize that their organizational decisions are inevitably technical decisions because of Conway's law. When the impact of Conway's law is not explicitly considered, things will often look random at the IC level. Too often, organizational leaders don't realize they are dictating technical outcomes with decisions that appear to just be about reporting structure.
An example is when a major new product feature comes along that is big enough to need multiple teams to build/own it for the long term. Where are those teams placed in the organization? Conway's law helps us see that a huge part of the future architecture is being determined by answering that question. Placing those new teams in an existing org mainly responsible for UX will result in a very different architecture than putting the new teams in an org mainly responsible for monetization. Can the teams be split across those orgs? Well, can you envision a reasonable architecture with an enforced divide along those lines? Without recognition of Conway's law, that last question might not be considered and the decision to split or not will be based on other factors.
Unfortunately that requires multidisciplinary thinking (technical architecture, resource allocation, communication structure, people development, ...). Such broad thinking is not always easy. When leadership starts neglecting one or more of these disciplines, more and more of the people doing the work on affected teams start perceiving the decisions as arbitrary and counter productive. Organizational churn (e.g., teams repeatedly changing location within the org over the course of a year or two) is often leadership looking at a different subset of these dimensions over time, yielding different "correct" answers.
If there’s no organizational barrier (e.g. microservices architecture, separate repos with strict permissions) that will prevent devs from leaking abstractions across technical boundaries, those well-defined modules and interfaces will devolve into a big ball of mud.
I say this with the assumption that the team is large and members regularly come and go.
Teams have natural tendency to produce separate modules from other teams so that they can manage their development process more effectively.
Then you can consider individual team members working on their own modules. In this case the modules also can be a reflection on how the task was delegated to the team because how you split the task between multiple team members may end up how the boundaries between modules were designed.
But it does not necessarily have to be this way. Design decisions should be made consciously and selecting how to break up your application into modules is an important design decision.
reply