Long horizons create pressure.
If something is meant to last, it feels like it should be designed properly. Scalable. Flexible. Future-proof.
So you add more.
More structure. More tooling. More decisions made upfront.
And slowly, the system becomes heavier than the problem it was supposed to solve.
The mismatch
The longer the horizon, the more you try to prepare for it.
You plan for edge cases. You introduce abstractions. You make things “ready” for what might come later.
It all makes sense.
That’s the problem.
Each decision is reasonable. Each addition is justified. But over time, they accumulate into something that is harder to change, harder to understand, and harder to keep alive.
That’s the pattern behind decisions like adopting infrastructure too early, something I wrote about in When Not to Use Kubernetes.
The reasoning is always solid.
It just doesn’t survive contact with time.
What actually matters
Over long horizons, the problem is not capability.
It’s survivability.
The system needs to keep working:
- when you lose context
- when priorities shift
- when you come back to it weeks later
Most systems don’t fail because they can’t do enough.
They fail because they become too heavy to carry.
What “small” actually means
Small is not about scope.
It’s about staying manageable over time.
A small system is:
- easy to understand after a break
- cheap to maintain
- easy to restart
- limited in moving parts
It doesn’t try to anticipate everything.
It stays close to the problem.
What actually holds up
Some systems last a long time.
Not because they were designed for every possible future.
But because they stayed simple enough to keep working.
You see this in older setups that are still in use today. Not perfect, not modern, but stable and understandable.
That’s closer to what’s happening in Maintaining a Symfony PHP App in 2026.
It didn’t survive because it was future-proof.
It survived because it stayed small enough to keep working.
Where complexity creeps in
The problem is that complexity rarely feels like overengineering.
It feels like improvement.
You clean things up. You generalize. You add structure so future changes are easier.
Individually, these are good decisions.
Collectively, they make the system heavier.
At some point, every change costs more than it should.
That’s when the system starts working against you.
Avoiding that is mostly about restraint.
Knowing when not to add the next layer.
That’s the same decision process behind How I Decide What Not to Build.
Personal systems follow the same rules
This isn’t just a software problem.
It’s easier to see outside of it.
With fitness, complexity feels productive.
You plan workouts, track everything, optimize diet, build routines that look complete.
They work. For a while.
Then they collapse.
What actually holds up is much simpler:
- a few exercises
- minimal structure
- something easy to resume
The same applies to learning Finnish.
It’s tempting to optimize everything. Apps, schedules, tracking systems.
But the version that survives is the one that stays simple enough to continue.
That’s what I ended up doing in Learning Finnish.
And it’s also why my writing system works the way it does. It avoids dependency on perfect conditions, as described in I Don’t Write Weekly.
The tradeoff
Small systems are not perfect.
They don’t cover every case. They don’t scale cleanly. They don’t look impressive.
Sometimes you redo things later.
But that cost is usually lower than carrying unnecessary complexity for months.
Rework later is cheaper than drag now.
Closing
Long horizons don’t require complex systems.
They require systems that can stay small for a long time.
Not because the goal is small.
Because the system needs to survive.
