Battling Software Scale and Complexity: Rescue, Cure, and Maintenance (Part 1)

From a Google Slide to a Bigger Insight

About ten years ago the author attended a software‑engineering conference in the United States where a Google speaker began with a single slide that left a lasting impression. The slide suggested that, while outsiders view Google as a high‑tech powerhouse, Googlers see it as a slow, labor‑intensive operation, having seen through the essence of modern software development.

The Essence of Software Development: Handcraft

The author argues that software development remains fundamentally a "handcraft". It still depends heavily on individual skill; this model works for small projects but breaks down as teams grow.

Scale vs. Complexity

When a project expands from a single developer to hundreds, the time required to deliver a feature jumps from half a day to several weeks. The core factor behind this efficiency loss is the exponential rise of software scale and complexity. The relationship is likened to a child's height versus weight: doubling height leads to a five‑fold weight increase, just as growing software size inevitably brings faster growth in complexity.

Two Layers of Complexity

Software complexity exists on two fronts: the system level and the development‑process level. For large systems, complexity is the norm rather than the exception.

Why Complexity Grows

Software cannot be perfectly designed from the start; it evolves through incremental modules, accumulating complexity over time. The author emphasizes that "software is grown, not designed"—an organic process akin to city development, unlike the repeatable, inorganic nature of industrial production.

Software Architecture vs. Building Architecture

Unlike building architects, who can separate design from construction, software architects must intertwine design and implementation. The architecture continuously iterates during implementation, and any addition (e.g., a new “balcony”) risks breaking the existing system.

Essential vs. Accidental Complexity

Essential complexity is inherited from the problem domain and cannot be eliminated without shrinking the domain. Accidental (or random) complexity is introduced by implementation choices and can be reduced. The author lists several typical sources of accidental complexity:

Case 1: Service C works around a defect in Service S while Service B does the same, leading to divergent workarounds.

Case 2: Introducing a NodeJS component into an otherwise Java‑only system adds unnecessary language complexity.

Case 3: Different team members use varied components or versions to achieve the same functionality, creating inconsistency.

Case 4: Newcomers add quick‑and‑dirty if‑else branches or copy‑paste code instead of refactoring the design.

Case 5: Inconsistent naming of the same business concept across modules, coupled with divergent implementations.

Case 6: Tight schedules cause design documents and code to diverge, adding hidden complexity.

…and many more similar examples.

These accidental complexities increase technical debt, coordination cost, and cognitive load, creating a vicious cycle that degrades development efficiency.

Loss of Control Over Complexity

Successful products inevitably grow, adding new features that increase both essential and accidental complexity. Longer product lifetimes mean historical complexity accumulates. Team expansion amplifies random complexity, as differing styles and goals introduce inconsistency. Re‑inventing wheels across departments further injects unnecessary complexity.

Three‑Step Strategy: Rescue, Cure, Maintenance

Rescue: Avoid "Deadline‑Driven Development" that forces teams to sacrifice quality for speed. Short‑term overtime may meet a deadline, but it pours random complexity into the system, leading to later slowdowns and architectural decay.

Cure: Adopt a slower, balanced approach that respects the trade‑off triangle of feature scope, quality, and schedule. Accept that rapid delivery at the expense of quality creates a “malicious cycle”.

Maintenance: When a project has survived its early survival phase, consider a clean‑slate replacement of backend services at a time when users are unaware, allowing a controlled transition.

The author notes that the next part will elaborate on the "cure" and "maintenance" phases.