Striking the Balance

A few patterns keep showing up in the projects I’ve worked on. They’re not new ideas, but they’re easy to forget when you’re deep in delivery. This is my attempt to write them down.

Local optimisation and its consequences

There’s a category of mistake that’s easy to make and hard to see while you’re making it: optimising one dimension of a system so aggressively that the costs land somewhere else entirely.

I saw this play out in a backup solution. The team put serious effort into making backups immutable — genuinely hard to tamper with, even under adversarial conditions. The threat model was thorough: stolen credentials across multiple actors, intentionally introduced bugs, coordinated attacks. The engineering was solid. For that specific goal, it worked.

But the friction spread well beyond the backup system itself. Routine operator tasks required multi-party approval — the kind of overhead that’s reasonable for a production database change, but grinding when you’re just running a scheduled job. Blanket SCPs put in place to prevent backup mutation ended up blocking operations in other teams who had nothing to do with backups. The policies weren’t scoped tightly enough, and the blast radius was wider than anyone intended.

The backup immutability was a real goal. But the optimisation was scoped to one metric — “how hard is it to corrupt a backup?” — without accounting for what it cost everything around it.

That’s the trap of local optimisation: the thing you’re measuring improves, and everything else quietly gets worse.

Scoping, prioritisation, and knowing when to re-prioritise

Prioritisation only works if the scope is clear. Without it, the work expands to fill whatever time is available — and often more.

A common version of this: a team sets aside a sprint to pay down technical debt. No clear boundaries on what’s in scope. The first day, someone fixes a known issue. The second day, they notice something adjacent. By the end of the sprint, half a dozen things are half-done and nothing has shipped. The sprint ends with more work in progress than when it started.

The problem isn’t that the team worked on tech debt. It’s that they treated it differently from feature work — without a defined scope, a clear “done,” or any mechanism to stop. Debt work needs the same discipline as everything else: a specific goal, a boundary around it, and a way to know when you’ve hit it.

The other side of this is being willing to re-prioritise when the context changes. Sticking rigidly to a plan that was made with last month’s information isn’t discipline — it’s inertia. The teams I’ve seen handle this well treat re-prioritisation as a normal part of the process, not an admission of failure. They make it fast, they make it visible, and they move on.

When to consider a rewrite

Refactoring is usually the right call. But not always.

There’s a particular failure mode I’ve seen more than once: a configuration system that starts simple and grows into something nobody fully understands. It begins as a YAML file with a few knobs. Then someone adds conditional logic. Then environment-specific overrides. Then a templating mechanism. Then escaping rules for the templating mechanism. Eventually you’re debugging logic in YAML, and the “config file” has become an untyped programming language with no editor support, no tests, and no debugger.

At that point, refactoring is the wrong tool. Each refactor touches a system where the behaviour isn’t fully understood and isn’t tested. You’re as likely to introduce bugs as fix them. A rewrite — with a proper DSL, or a real scripting layer, or just a clearly defined data format — is cheaper in the long run than continuing to patch something that was never designed for what it became.

The signal that a rewrite is worth considering isn’t age or size. It’s when the cost of understanding the existing system exceeds the cost of rebuilding it with what you now know. That’s a judgement call, and it’s often made too late.

Simplicity over flexibility

The instinct to build flexibly is understandable. Requirements change. You don’t want to paint yourself into a corner. So you add extension points, plugin hooks, generic interfaces — designing for the use cases you don’t have yet.

The problem is that flexibility has a cost, and it’s paid upfront. Every abstraction layer is something the next engineer has to understand before they can change anything. Every extension point is a place where behaviour becomes implicit rather than explicit. The system becomes harder to reason about, not easier.

I’ve seen this in internal frameworks built to be reusable across teams. The intention is good: write it once, use it everywhere. But the framework has to be generic enough to serve every possible consumer, which means it can’t be optimised for any of them. Teams end up building adapters on top of the framework to make it work for their specific case — which is exactly what they were trying to avoid.

The simpler version — written for the actual use case, not the hypothetical one — would have been easier to change when requirements shifted. Flexibility in a system often creates rigidity in its consumers.

Prefer the simpler design. Handle the actual problem in front of you. If the requirements change in a way that breaks the design, refactor then — with real information instead of speculation.

None of these are new ideas. The hard part is remembering them when you’re in the middle of a deadline and the tempting option is right in front of you.