💬 "These were elucidated in the mid-70s by Yourdon & Constantine in "Structured Design" and haven't changed. Their argument goes like this:
1. We design software to reduce its cost.
2. The cost of software is ≈ the cost of changing the software.
3. The cost of changing the software is ≈ the cost of the expensive changes (power laws and all that).
4. The cost of the expensive changes is generated by cascading changes — if I change this then I have to change that and that, and if I change that then…
5. Coupling between elements of a design is this propensity for a change to propagate.
6. So, design ≈ cost ≈ change ≈ big change ≈ coupling. Transitively, software design ≈ managing coupling.
(This skips loads of interesting stuff, but I'm just trying to set up the argument for why rapid decomposition of a monolith into micro-services is counter-productive.)"
-- "Monolith -> Services: Theory & Practice" by Kent Beck
1. We design software to reduce its cost.
2. The cost of software is ≈ the cost of changing the software.
3. The cost of changing the software is ≈ the cost of the expensive changes (power laws and all that).
4. The cost of the expensive changes is generated by cascading changes — if I change this then I have to change that and that, and if I change that then…
5. Coupling between elements of a design is this propensity for a change to propagate.
6. So, design ≈ cost ≈ change ≈ big change ≈ coupling. Transitively, software design ≈ managing coupling.
(This skips loads of interesting stuff, but I'm just trying to set up the argument for why rapid decomposition of a monolith into micro-services is counter-productive.)"
-- "Monolith -> Services: Theory & Practice" by Kent Beck