Conway's Law
melconway.com
melconway.com
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.
We shape our buildings; thereafter they shape us.
--Winston Churchill
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.
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?
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...")
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."