Yes. The big company becomes a victim of its own size and history of choices. The way they set the company up 10 years ago (or more) will still echo in everything done today. For better or worse.
I've actually been wondering about this in regard to microservices. As people switch from monolithic architecture (where one war or package might have both frontend and backend) to microservice architecture, are you finding it useful and necessary to change your team structures? A lot of place have product-focused teams with frontend and backend people mixed together, but as products become more about frontends consuming services, it seems that might imply a different team structure is better. (And kind of a variation of how Conway's law is stated in the OP since the architectural progression is driving the team structure, rather than the other way around.)
Well, I'm sort of running that logic in the reverse direction... I'm pushing microservices because our organization is already set up with a lot of independence in the teams, and we've been struggling for years with coding methodologies that fight that by trying to enforce monolithic coding practices.
Conway's law is really important, but like mathematical equality, it doesn't really have a direction. You can bring organization into conformance with code, or code into conformance with organization. The full situation, as always, may suggest one or the other is a better idea, but Conway's law just says that you really need to do one or the other, or you'll pay a price. (Which may also be one you find yourself having to pay for other reasons... sigh... "ask not an engineer whether something is a good idea, for he shall say neither yea nor nay...")
Oh yeah. I've worked in on a couple of products where there was a "client floor" and a "server floor" and the two groups would integrate their stuff every three or four months . . . or five, or six. Didn't work all that well.
At the last place I remarked that a better seating arrangement for the project would have been to place everyone at random, and I wasn't kidding.
I really like the model of movable desks. An engineer and a finance person need to sit together for a while? Just find a spot, or make room where one of the parties happens to be. Oh, we need a designer, and a lawyer? That's easy. Need to go find a spot where you can work alone for a couple of weeks? Done. Of course, this sends shivers up the spines of people who feel the need to exert control in the workplace.
You're still up against Dunbar's number. At some point you can't keep everyone in your head. Meatware doesn't scale well yet.
"Of course, this sends shivers up the spines of people who feel the need to exert control in the workplace."
I'm not sure who you mean here. As an employee, I would dislike moving around a lot as I like to, for example, have a picture of my wife on my desk, or have a pair of headphones I leave at the desk so I don't have to lug them back and forth between home and work. I also have some useful physical references I keep around and have physical (paper) files I need to keep track of for my job. Having to move all of those things or having them in a place other than within arm's reach at my desk would make me less productive. If trying to remain productive means "feeling the need to exert control in the workplace," then yeah, guilty as charged.
Other than that, I like the idea of mixing up who sits where, so long as it's for relatively long periods of time. Weeks at least, preferably months. It would be annoying to have to move every few days.
Moving every few days would be bad. (I usually stay in the same spot for 4-6 months). The desk has wheels: It's just a matter of unplugging two cables and rolling desk+chair to a new spot. Since I've got a couple of computers on the floor, this takes two trips and maybe 15 minutes, most of which is waiting for the slow freight elevator. Picture of my wife stays in place the whole time.
In the 80s and 90s I used to keep a whole bookshelf in my office. Took days to move (get boxes, fill them, have moving people move them, unbox, etc.).
I've pruned this down to one or two books. Everything else is online, and it's fine. I could see that requiring a bunch of physical references would be a problem.
I'm sure it's willful blindness on my part, but in 30 years, I can't think of a single example of a design I've helped create that was a reflection of the organization's communication structure. I've built object databases, distributed share-nothing databases, a sentiment extraction system, and a mobile geo-locations application. Can anyone give a real world example of Conway's law?
You have two teams that work on different systems. A feature needs to be built that crosses the two systems. Do you:
a) Build a temporary team with 2 developers from each team.
b) Create a spec and hand it to Team 1. Team 1 adds an API for Team 2 to consume. Team 2 gets the API spec from Team 1 and integrates.
In situation (a), it's likely your solution will blur the line between system 1 and system 2. The solution will be very specific and implementation details on each side will be blurred together influencing the result.
In situation (b), it's likely that the API on system 1 is more generic and less coupled to the implementation details of system 2.
Situation (a) is generally faster to market. Situation (b) is generally easier to maintain, but can be much, much slower.
A specific example I've seen recently is a web server written in C doing string manipulation and a javascript client consuming data from this API.
If I'm working closely with the frontend developer, I'm going to say "How about I send you the data raw, and you split on this sequence". Splitting in javascript is much simpler than strtok_r and as a bonus I offload the processing to the client. From a development standpoint, it takes 2 minutes to coordinate.
If I'm not working with the frontend team, then I'm probably going to go through the trouble of doing the string manipulation server side.
Does that make sense? (not the design itself, but as an explanation of how communication influences design).
I didn't find that simple at all >_<. Your example works, though, I fear you're getting way to granular for the application of Conway's Law, which talks more to how applications map to departments/power structures.
edit: Thinking further, I think that for Conway's Law to apply, it isn't so much about time/cost/complexity tradeoffs, but more about constraints due to your org structure and communication. Conway's Law would be more acute if due to some communication constraint in your company (e.g. regulatory, politics, incompetence), you were forced to go with choice A or choice B (e.g. information silo).
Information silos are the de facto example of Conway's Law. For example, maybe the sales team for a regional office wants to run reports, but doesn't have access to corporate HQ's MIS. The sales team's SYSTEM is constrained by the ORGANIZATION COMMUNICATION STRUCTURE. If the regional sales team can lobby successfully for access, they'll be able to hook in to corporate. If not, the sales team will roll their own MIS as a workaround and create a mini-empire. The result provides inferences about the org's communication structure.
I typically think of what the ideal solution is, then compare that to the actual systems architecture. From that systems footprint, you can usually tell which dept.'s communicate well and which departments have disproportionate power.
I think HTTP2 is a good example. HTTP2 is the result of trying to avoid changing TCP at all costs. This reflects the communication structure of people developing TCP and HTTP.
Keeping in mind that Conway's law is about systems not just software systems, the example I heard was:
Suppose a company wants to redesign its production system. It has two factories, so the new production system will have two parts. Each factory has a general manager and a production manager so the new production system will have a general manager console interface and a production manager console interface. And so on.
Thinking about it myself, an obvious example is group permissions and user permissions in a network environment. What this illustrates is that Conway's law is often so natural that we don't even think about it until we create an impedance mismatch between the organization and the system.
We shape our buildings; thereafter they shape us.
--Winston Churchill
Google being famously bad at customer support is I'm pretty sure a real life Conway's law. Google likes to put support as close to engineering as possible which biases towards "scalable" support over just throwing bodies at the problem.
It turns out support is one of those areas where just throwing bodies at the problem is often the right answer which leads to the kind of support nightmares that people encounter.
This is one of the most important comupter science laws out there, yet, people mostly treat it as a joke.
Anyway, the bottom line is that the teams should be built in such a way as to reflect desired architecture of the project. If you fail to do that, the project will end up with shitty architecture.
"... all things being equal, a software effort that pays attention to and actively aligns social structure with technical structure will fare better than one that does not."
I think this emperor has no clothes! Take distributed concensus protocols: two-phase-commit (or RAFT et al). I have never worked in an organization that adopted a 2PC communication protocol. The only real-world example I know is a wedding ceremony: "Do you Jane, take Tarzan to be your ape-man? (Jane says 'I do') And do you Tarzan, take Jane to be your swinging partner (Tarzan says 'Woo hoo!'). I now pronounce you husband and wife (because you've each locally committed)" Can you imagine working in a place like that? And yet 2PC is part of most database design.
Or take a design that consists of functional transformations of a sequence of ASTs. What organizational communication structure is stateless? ("Don't tell me you already told me that a minute ago! I refuse to remember anything you say. ever. You want to tell me something, start from the beginning every time. And furthermore, I refuse to talk to you at all unless we're given an entirely new language in which to express our conclusions. Besides, you're nothing but a monad to me") Ridiculous for human communication, but arguably essential for large-scale distributed parallel computation.
Or take event-bubbling, or model-view-controller. Does any organizational communication system use those in anything other than a once-in-a-blue-moon, accidental way?
27 comments
[ 0.24 ms ] story [ 58.1 ms ] threadConway's law is really important, but like mathematical equality, it doesn't really have a direction. You can bring organization into conformance with code, or code into conformance with organization. The full situation, as always, may suggest one or the other is a better idea, but Conway's law just says that you really need to do one or the other, or you'll pay a price. (Which may also be one you find yourself having to pay for other reasons... sigh... "ask not an engineer whether something is a good idea, for he shall say neither yea nor nay...")
At the last place I remarked that a better seating arrangement for the project would have been to place everyone at random, and I wasn't kidding.
I really like the model of movable desks. An engineer and a finance person need to sit together for a while? Just find a spot, or make room where one of the parties happens to be. Oh, we need a designer, and a lawyer? That's easy. Need to go find a spot where you can work alone for a couple of weeks? Done. Of course, this sends shivers up the spines of people who feel the need to exert control in the workplace.
You're still up against Dunbar's number. At some point you can't keep everyone in your head. Meatware doesn't scale well yet.
I'm not sure who you mean here. As an employee, I would dislike moving around a lot as I like to, for example, have a picture of my wife on my desk, or have a pair of headphones I leave at the desk so I don't have to lug them back and forth between home and work. I also have some useful physical references I keep around and have physical (paper) files I need to keep track of for my job. Having to move all of those things or having them in a place other than within arm's reach at my desk would make me less productive. If trying to remain productive means "feeling the need to exert control in the workplace," then yeah, guilty as charged.
Other than that, I like the idea of mixing up who sits where, so long as it's for relatively long periods of time. Weeks at least, preferably months. It would be annoying to have to move every few days.
In the 80s and 90s I used to keep a whole bookshelf in my office. Took days to move (get boxes, fill them, have moving people move them, unbox, etc.).
I've pruned this down to one or two books. Everything else is online, and it's fine. I could see that requiring a bunch of physical references would be a problem.
Or laptops.
You have two teams that work on different systems. A feature needs to be built that crosses the two systems. Do you:
a) Build a temporary team with 2 developers from each team.
b) Create a spec and hand it to Team 1. Team 1 adds an API for Team 2 to consume. Team 2 gets the API spec from Team 1 and integrates.
In situation (a), it's likely your solution will blur the line between system 1 and system 2. The solution will be very specific and implementation details on each side will be blurred together influencing the result.
In situation (b), it's likely that the API on system 1 is more generic and less coupled to the implementation details of system 2.
Situation (a) is generally faster to market. Situation (b) is generally easier to maintain, but can be much, much slower.
A specific example I've seen recently is a web server written in C doing string manipulation and a javascript client consuming data from this API.
If I'm working closely with the frontend developer, I'm going to say "How about I send you the data raw, and you split on this sequence". Splitting in javascript is much simpler than strtok_r and as a bonus I offload the processing to the client. From a development standpoint, it takes 2 minutes to coordinate.
If I'm not working with the frontend team, then I'm probably going to go through the trouble of doing the string manipulation server side.
Does that make sense? (not the design itself, but as an explanation of how communication influences design).
edit: Thinking further, I think that for Conway's Law to apply, it isn't so much about time/cost/complexity tradeoffs, but more about constraints due to your org structure and communication. Conway's Law would be more acute if due to some communication constraint in your company (e.g. regulatory, politics, incompetence), you were forced to go with choice A or choice B (e.g. information silo).
Information silos are the de facto example of Conway's Law. For example, maybe the sales team for a regional office wants to run reports, but doesn't have access to corporate HQ's MIS. The sales team's SYSTEM is constrained by the ORGANIZATION COMMUNICATION STRUCTURE. If the regional sales team can lobby successfully for access, they'll be able to hook in to corporate. If not, the sales team will roll their own MIS as a workaround and create a mini-empire. The result provides inferences about the org's communication structure.
I typically think of what the ideal solution is, then compare that to the actual systems architecture. From that systems footprint, you can usually tell which dept.'s communicate well and which departments have disproportionate power.
Suppose a company wants to redesign its production system. It has two factories, so the new production system will have two parts. Each factory has a general manager and a production manager so the new production system will have a general manager console interface and a production manager console interface. And so on.
Thinking about it myself, an obvious example is group permissions and user permissions in a network environment. What this illustrates is that Conway's law is often so natural that we don't even think about it until we create an impedance mismatch between the organization and the system.
Captures a bit of it I suppose.It turns out support is one of those areas where just throwing bodies at the problem is often the right answer which leads to the kind of support nightmares that people encounter.
Anyway, the bottom line is that the teams should be built in such a way as to reflect desired architecture of the project. If you fail to do that, the project will end up with shitty architecture.
Christian Bird's chapter in Making Software (https://books.google.com/books?id=DxuGi5h2-HEC&pg=PA187&lpg=...) turns Conway's Law on its head with Conway's Corollary. Instead of fighting organizational bias, embrace it.
"... all things being equal, a software effort that pays attention to and actively aligns social structure with technical structure will fare better than one that does not."
Or take a design that consists of functional transformations of a sequence of ASTs. What organizational communication structure is stateless? ("Don't tell me you already told me that a minute ago! I refuse to remember anything you say. ever. You want to tell me something, start from the beginning every time. And furthermore, I refuse to talk to you at all unless we're given an entirely new language in which to express our conclusions. Besides, you're nothing but a monad to me") Ridiculous for human communication, but arguably essential for large-scale distributed parallel computation.
Or take event-bubbling, or model-view-controller. Does any organizational communication system use those in anything other than a once-in-a-blue-moon, accidental way?