4 ms·

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 organ

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?

phamilton 11y ago
Simple example: 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).
- caminante 11y ago
  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).
  - phamilton 11y ago
    Conway's law is all about communication structure. Abstractions and constraints in communication influence abstraction and constraints in software.
- sukilot 11y ago
  Situation B is often a very clean solution to an irrelevant problem, with layers of extra overengineered complexity .
  - phamilton 11y ago
    The beauty of Conway's law is that your statement applies to both the code itself and the communication structure of the org.
caminante 11y ago
I'm sure that you encountered it. 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.
sanxiyn 11y ago
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.
brudgers 11y ago
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 Captures a bit of it I suppose.
shalmanese 11y ago
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.

phamilton 11y ago

Simple example: 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).

caminante 11y ago
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).
- phamilton 11y ago
  Conway's law is all about communication structure. Abstractions and constraints in communication influence abstraction and constraints in software.
sukilot 11y ago
Situation B is often a very clean solution to an irrelevant problem, with layers of extra overengineered complexity .
- phamilton 11y ago
  The beauty of Conway's law is that your statement applies to both the code itself and the communication structure of the org.

caminante 11y ago

I'm sure that you encountered it. 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.

sanxiyn 11y ago

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.

brudgers 11y ago

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 Captures a bit of it I suppose.

shalmanese 11y ago

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.