#Balanced Coupling

I was recently asked this question on LinkedIn. My short answer: yes. But the more interesting question is why, and why AI might make them more relevant, not less.

Reframing the Question

Some say SOLID principles are outdated. They’re not. SOLID principles are guidelines for designing modular systems. They address forces that exist in software regardless of who (or what) produces the code. AI changes the author. It doesn’t change the physics of software complexity.

If anything, AI amplifies the need for modular design. We can now generate code at unprecedented speed. That’s a double-edged sword. You can build a well-structured system faster than ever. But poor design decisions will accumulate technical debt at a pace we’ve never seen before.

[Read More]

“Words should be weighed, not counted.” — A Yiddish Saying

Static code analysis tools count dependencies, calculate ratios, and assign neat scores. Yet in my experience, chasing those metrics never really made the design more modular. It’s so easy to game the scores without any improvement to the design itself. Let’s see why, and what you can do instead.

The Counting Approach

Most static analysis tools evaluate coupling by counting dependencies. Afferent coupling (Ca) counts how many components depend on yours. Efferent coupling (Ce) counts how many components yours depends on. A popular instability metric combines them into a neat formula:

I = Ce / (Ce + Ca)

The higher the ratio of outgoing to total dependencies, the more “unstable” a component is considered. Simple. Automatable. And deeply misleading.

[Read More]

Every other post on my feed celebrates how AI lets us write code faster: whole apps built in a matter of a few hours, 99% AI-generated codebases, hundred-fold productivity gains, and on and on. But does writing code faster actually make us more productive?

A Quick Detour Through a Factory

The Theory of Constraints says that every system’s throughput is limited by a single constraint: its bottleneck. What makes a system more effective? Improving the bottleneck. What makes a system less efficient? Improving anything else.

I know, that second part is counterintuitive. Here’s the thing: if you speed up a non-bottleneck, you don’t improve the system; you produce more work-in-progress that piles up in front of the bottleneck! More inventory. More cost. More waste. The system becomes more expensive to operate, not more productive.

This is a well-established principle in manufacturing, and software manufacturing is no exception.

[Read More]