Software Design Doesn’t Scale (and It’s Costing Us)

Software systems keep getting more powerful, more connected, and more critical to how organisations operate.

Yet if you talk to experienced engineers, a strange pattern emerges:

despite better tools, faster hardware, and more sophisticated platforms, software design feels harder, slower, and more fragile than it should.

Teams grow, processes mature, and budgets increase — but design quality does not scale in proportion. Instead, complexity accumulates. Specialist knowledge becomes a bottleneck. Coordination costs rise. Trade-offs harden into permanent constraints.

This isn’t a tooling problem.

It’s not a talent shortage.

And it’s not something agile ceremonies or better documentation can fix.

The core issue is that software design does not scale economically with system complexity.

The pattern we’ve normalised

As systems grow, organisations respond in predictable ways:

• We add more engineers.
• We create more roles and sub-teams.
• We introduce frameworks, platforms, and shared services.
• We standardise, abstract, and modularise.

Each of these helps — briefly.

Over time, the same failure modes reappear:

• Architectural decisions become harder to change.
• Performance regressions appear far from their causes.
• Deep expertise gets stretched thin across too many concerns.
• Coordination consumes more effort than actual design.

We’ve largely accepted this as “just how software works”.

That acceptance is the real problem.

Software design is still a craft, not an industry

In mature industries — manufacturing, logistics, construction — complexity is handled through specialisation and supply chains. No single organisation designs everything end-to-end. Instead, specialised contributors deliver well-defined components, each with clear responsibilities and interfaces.

Software, by contrast, still treats design as a largely monolithic activity.

Even when code is modular, design expertise isn’t. Architectural judgement, performance tuning, concurrency modelling, security reasoning — these live in people’s heads and team processes, not in reusable industrial units.

The consequences are structural:

• Specialist knowledge does not compound.
• Every project re-pays the same design costs.
• Deep expertise becomes a coordination liability instead of a scalable asset.

We’ve industrialised code reuse.

We haven’t industrialised design reuse.

A concrete example: the performance specialist trap

Consider a system under load.

It works fine initially, but as usage grows, latency spikes appear in edge cases. Eventually, a performance specialist is brought in.

They analyse the system, identify cache invalidation paths, memory layout issues, and scheduling interactions. Changes are made. Performance improves.

Six months later, the system evolves. A new feature interacts badly with the original assumptions. Performance degrades again.

Nothing “failed” — except the scalability of expertise.

The specialist’s reasoning wasn’t preserved as a reusable design input. It remained embedded in human context, documentation, and tribal memory. Each revisit incurs the same cognitive and coordination cost.

Multiply this pattern across architecture, security, correctness, and reliability — and you get today’s software economics.

Why better teams don’t fix this

A common objection is that this is simply a people problem.

If we hire better engineers, build stronger teams, and invest inculture, these issues go away.

There’s truth here — but only up to a point.

Strong teams absolutely outperform weak ones.

But even elite teams hit structural limits:

• Specialist knowledge still bottlenecks decision-making.
• Expertise must be synchronised across time and change.
• Coordination effort grows non-linearly with system size.

At some scale, the problem stops being how good the team is and becomes how design work itself is organised.

No amount of talent removes the need for an industrial abstraction.

The hidden cost: forced generalism

Because specialist expertise doesn’t scale well, organisations quietly compensate by encouraging generalism.

Engineers are expected to:

• Understand architecture, performance, security, and delivery.
• Move fluidly across layers.
• Make “reasonable” trade-offs under time pressure.

This works — until it doesn’t.

Generalists are invaluable, but forced generalism dilutes depth. Critical design decisions get made with partial understanding because waiting for specialists is too expensive or slow.

The system still ships.

But latent risk accumulates.

That risk shows up later as outages, rewrites, compliance failures, or permanent architectural scars.

Platform teams as accidental monopolies

• Expertise is still tied to a specific team.
• Scaling requires scaling headcount.
• Knowledge becomes siloed behind organisational boundaries.

When platform assumptions no longer fit, consumers are stuck. The abstraction leaks, and deep expertise must be reintroduced — urgently.

Again, the issue isn’t bad execution.

It’s that expertise delivery remains time-bound and team-bound.

The thesis, plainly stated

Let’s state the thesis explicitly:

Software design does not scale because specialist expertise cannot currently be delivered as a reusable, accountable, industrial input.

Until that changes, we will keep paying the same design costs repeatedly — no matter how good our tools become.

This is not about automation (yet)

At this point, many people jump to AI or code generation.

That’s premature.

Automation can accelerate execution, but it does not solve the structural problem of expertise delivery. If anything, automation without clear responsibility boundaries amplifies risk.

The problem to solve first is organisational and economic:

• How is design expertise packaged?
• How is it reused?
• How are responsibility and liability assigned?

Automation is a consequence of getting those answers right — not the starting point.

What comes next

What abstraction are we missing?

In other industries, the answer was a supply chain.

In software, that idea sounds uncomfortable — even alien — because we’re used to thinking in terms of teams and projects.

In the next post, I’ll introduce the missing abstraction directly, and explain what a Software Design Supply Chain actually means in practice — without hand-waving or buzzwords.

Key takeaways

• Software design effort does not scale economically with system complexity.
• Specialist expertise is still delivered as time-bound human effort.
• Teams, platforms, and tools optimise execution but not structure.
• Forced generalism hides cost by accumulating latent risk.
• The core problem is organisational and economic, not technical.

• Part 1 — Software Design Doesn’t Scale (and It’s Costing Us)
• Part 2 — The Missing Abstraction: A Software Design Supply Chain
• Part 3 — Encapsulated Expertise: Specialists Without Headcount
• Part 4 — Emergent Coding: Automation as a Consequence, Not a Goal

This post is Part 1 of the series.

In Part 2, I’ll introduce the Software Design Supply Chain itself — and why it’s the only abstraction I’ve found that actually breaks the scaling trap.

If this resonates, follow along for the next post — or share it with someone who’s felt this problem but couldn’t quite name it.