Why Managing Complexity Is Futile—and What Actually Improves Software Design

Inspired by Ferd’s essay, the author explains that complexity is inevitable in software; it can only be transferred between components, and library authors inevitably make their own code more complex to hide that complexity from users.

As the original quote says, “Complexity has to live somewhere. If you are lucky, it lives in well‑defined places,” so we must acknowledge its existence and manage it in locations everyone understands.

Two common reasons abstractions leak are that runtime costs cannot be hidden—different implementations may have the same logic but different performance—and that failures force engineers to “open the hood,” exposing low‑level details.

The author also describes a subjective sense of complexity, citing Kent Beck’s “Local Consequence” idea: we would like every change to be confined to a small, understandable area, but this is impossible in practice.

Organizing code by page

Organizing by data ownership

Organizing by a single business flow

Organizing by regional language version

Organizing by market‑specific customization

Grouping code that reads the same variable

Grouping code that writes the same variable

Grouping code simply because the same team owns it

These principles often conflict, so we rely on experience to prioritize high‑frequency changes and make them easy to modify, even though we cannot predict every future change.

Eliminating duplication is a powerful way to reduce complexity. Successful examples include:

PyTorch’s automatic generation of backward‑pass code from the forward pass.

Vue’s reactivity system that re‑executes getters after dependencies change.

React’s single render function with virtual‑DOM diffing.

Airtable’s form CRUD logic, where most code is identical across forms.

gRPC’s code generation for symmetric RPC structs.

When duplication is identified, a new framework or pattern can be built to remove it, thereby eliminating a portion of the overall complexity despite the effort required.

The author concludes that trying multiple approaches and embracing layered designs remains essential, as software architecture is a social science with practical limits, but there is still ample room for improvement.

Source: https://zhuanlan.zhihu.com/p/138145081