The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems.
Why do large systems disintegrate?
-- How Do Committees Invent?, Melvin Conway
First, It is a natural temptation of the initial designer to delegate tasks when the apparent complexity of the system approaches his limits of comprehension. ... Either he struggles to reduce the system to comprehensibility and wins, or else he loses control of it.
Second, application of the conventional wisdom of management to a large design organization causes its communication structure to disintegrate.
One fallacy behind this calculation is the property of linearity which says that two men working for a year or one hundred men working for a week are resources of equal value. ...
Assuming that two men and one hundred men cannot work in the same organizational structure our homomorphism says that they will not design similar systems; therefore the value of their efforts may not even be comparable. ...
From experience we know that the two men, if they are well chosen and survive the experience, will give us a better system.
The second step in the disintegration of a system design -- the fragmentation of the design organization communication structure -- begins as soon as delegation has started.
Third, the homomorphism insures that the structure of the system will reflect the disintegration which has occurred in the design organization.
Probably the greatest single common factor behind many poorly designed systems now in existence has been the availability of a design organization in need of work.
Another implication of Conway’s Law is that if we have managers deciding on teams, and deciding which services will be built, by which teams, we implicitly have managers deciding on the system architecture.
— @ruthmalan on Conway’s Law
Conway’s Law also kicks in if we take an initial guess at the system decomposition allocate subsystems to teams, and sally forth–the team boundaries will tend to become boundaries within the system.
Anything else will be a feat of architectural heroics; hard to accomplish, when architectural heroics have to compete with schedule heroics driven by the steady beat of integration clocks.
Conway's Law:
We can view a system as a linear graph.
Each node is a subsystem which communicates with other subsystems along the branches.
Each subsystem may contain a structure similarly portrayed.
"Interface" refers to the inter-subsystem communication path or branch.
The linear-graph notation is useful because it provides an abstraction that has the same form for the two entities we are considering:
the design organization
and the system it designs.
Replace "system" with "committee."
Replace "subsystem" with "subcommittee."
Replace "interface" with "coordinator."
Just as with systems, we find that design groups can be viewed at several levels of complication.
... organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.
-- How Do Committees Invent?, Melvin Conway
(aka Conway's Law)
... we have found a criterion for the structuring of design organizations: a design effort should be organized according to the need for communication.
This criterion creates problems because the need to communicate at any time depends on the system concept in effect at that time. Because the design which occurs first is almost never the best possible, the prevailing system concept may need to change.
... we have demonstrated that there is a very close relationship between the structure of a system and the structure of the organization which designed it.
— How Do Committees Invent?, Melvin Conway
This kind of a structure-preserving relationship between two sets of things is called a homomorphism.
— How Do Committees Invent?, Melvin Conway
... it is reasonable to assume that for any system requirement there is a family of system designs which will meet that requirement, we must also inquire whether the choice of design organization influences the process of selection of a system design from that family.
... the very act of organizing a design team means that certain design decisions have already been made, explicitly or otherwise. ...
— How Do Committees Invent?, 6th par, Mel Conway
... Given any design team organization, there is a class of design alternatives which cannot be effectively pursued by such an organization because the necessary communication paths do not exist. ...
— How Do Committees Invent?, 6th par, Mel Conway
... Therefore, there is no such thing as a design group which is both organized and unbiased.
— How Do Committees Invent?, 6th par, Mel Conway
#ContinuousIntegration Pro-tip (of course I mean single branch):
Start adopting the expand-contract pattern.
Expand-contract is what blue-green deployments do.
You expand by installing a new version of the app, and then you contract by removing the old version.
Expand-contract is also heavily used for zero-down time database schema changes.
Let’s say you need to rename a table column.
You expand by adding a new column with the new name.
Feed the new column with data.
Once the app uses the new column, contract by removing the old one.