1. Coupling and Cohesion (Technical Origins)

Why Start with Software

Software makes structural problems easier to see. In many fields, failure can be blamed on personalities, politics, bad timing, or bad luck. Software is less forgiving. When systems fail in production, the structure underneath is often exposed very quickly. Hidden dependencies appear. Unclear ownership appears. Weak boundaries appear.¹

That makes software useful beyond engineering itself. If we can clearly describe why some software systems become fragile while others remain adaptable, we can ask whether the same structural patterns appear in organizations, governments, and institutions under different names.

This chapter stays mostly technical on purpose. The broader social parallels will come later. For now, the goal is simpler: understand the mechanics clearly before translating them elsewhere.

Coupling: How Much One Thing Depends on Another

Coupling describes how much one part of a system depends on another part of the system. No system has zero coupling. That is not the goal. Systems need cooperation to function. The real question is whether those dependencies are clear, limited, and stable—or whether they are hidden, fragile, and constantly changing.²

Tight coupling means small changes spread easily across the system. A database field changes and five services break. One team deploys late and another team's release fails. A shared library behaves slightly differently and unrelated features suddenly stop working.³

At first, these problems look technical. Over time, they become organizational. Teams spend more energy coordinating around fragility than improving the system itself. Meetings multiply. Deployment risk grows. More work goes into preventing failure than creating value.

Loose coupling does not eliminate dependency. It makes dependency easier to see and easier to manage. Good interfaces help contain change. Clear contracts reduce surprises. Failure becomes easier to diagnose because the paths between components remain visible.⁴

Cohesion: Whether a Thing Actually Belongs Together

Cohesion describes how well the responsibilities inside a component fit together. A highly cohesive system has a clear purpose. Its parts support the same job. Changes inside it tend to move in the same direction.

Low cohesion means unrelated responsibilities have been mixed together.⁵ This often looks efficient at first. A single service handles billing, notifications, permissions, reporting, and user management because putting everything in one place feels faster in the short term. But over time, the system becomes harder to reason about. Different teams modify the same code for unrelated reasons. Ownership becomes blurry. Small changes create unexpected side effects because too many concerns share the same space.

High cohesion protects local understanding. It allows people to improve one part of the system without needing to understand the entire organization around it.

Interfaces vs. Entanglement

An interface is a clean boundary for cooperation. Entanglement is dependence without a clean boundary. Interfaces make assumptions visible. Entanglement hides assumptions inside deployment timing, tribal knowledge, undocumented behavior, and human memory.

This is why some failures repeat over and over inside organizations. The problem is not that nobody noticed the failure. The problem is that the system has no clear place for the learning to land. The same mistakes return because responsibility is spread across too many unclear boundaries.

This is where the technical language starts becoming social language. Clear interfaces support clearer responsibility. Entanglement spreads responsibility so widely that nobody fully owns the outcome.

Feedback and Ownership

Systems improve only when consequences can return to the people who can change the design. If the people making architectural decisions also experience the operational pain those decisions create, learning happens. Systems adapt.⁶

If the pain is absorbed somewhere else, the learning loop weakens. Metrics may still look healthy. Reports may still look successful. But design debt quietly accumulates because the people paying the operational cost are not the people controlling the structure.⁷

In software organizations, this often appears as:

• handoff-heavy workflows,
• unclear on-call ownership,
• or architecture decisions made by people who never operate the systems they design.

The same structure appears outside software. A government agency may divide authority across separate departments. One group creates policy. Another handles operations. Another controls funding. When a preventable failure happens, each group can accurately explain its own role. But no group fully experiences both the consequences and the authority needed to redesign the system. The organization can document failure without reliably learning from it.

Toward the Book's Working Grammar

This chapter establishes the technical foundation for the rest of the book:

• Cohesion describes the internal integrity of a bounded unit.
• Coupling describes how consequences travel between units.
• Feedback determines whether systems learn or decay.

The broader translation is straightforward: cohesive systems support coherent ownership, and intentional coupling keeps consequences close enough to improve judgment.

The next chapter extends this into responsibility itself: who owns what, where boundaries should exist, and what happens when consequences drift too far from decision-making.

Cohesion determines ownership.

Coupling determines feedback.

Footnotes

1. Gene Kim et al., The DevOps Handbook. Used here for feedback-loop and operational-learning framing in software delivery. ↩

2. Robert C. Martin, Clean Architecture. Boundary and dependency framing for software components. ↩

3. Martin Fowler, Refactoring (with related architecture essays). Used here for change-coupling and fragility patterns in evolving codebases. ↩

4. Alistair Cockburn, Hexagonal Architecture writings. Used here for interface-boundary discipline and dependency containment. ↩

5. Robert C. Martin, Clean Architecture. Used here for cohesion-oriented boundary design and stable reasons to change. ↩

6. DORA research reports on software delivery performance and feedback speed. ↩

7. Gene Kim et al., The Phoenix Project and The DevOps Handbook on proximity between builders and operators. ↩