The Only Way to Truly Go Fast Is to Go Well

My friend Steve told me recently that there are two pills you can choose from, but you can only take one:

• Embrace fast features and it’ll soon break.
• Embrace resiliency and reliability, but ship slower.

I’m on the resiliency pill, by design.

Or I try really hard to be. Sometimes budget reality puts us in tech-debt-management mode instead. When it does, we keep the debt visible and push the resiliency case every chance we get.

I’ve been chewing on his framing ever since, because he’s not wrong about how most teams actually experience the choice. The pressure to ship is constant. The case for upgrades, restores, real test coverage, and security patches always sounds like the thing you do later, after the deadline, when there’s room.

But I think the dichotomy is a trick of the timeline. Zoom out far enough and it inverts.

Two pills, one choice

The framing isn’t unique to Steve. Every team I’ve worked with has felt some version of it.

You can hit the goal date, or you can keep the test suite honest. You can ship the feature this quarter, or you can take the Rails patch this quarter. You can do the new build, or you can exercise the restore process you’ve been meaning to exercise. One side of the ledger is visible to the people who pay you. The other side isn’t, until something breaks.

So the resiliency pill loses, again and again, in the calculus most teams actually run. Not because anybody thinks reliability is a bad idea, but because the next feature has a stakeholder and the next backup test doesn’t.

I want to grant all of that, because I think it’s how this choice is really lived.

It’s worth saying that not every version of the fast pill is reckless. Technical debt taken on purpose, named on a list somewhere, and paid down on a schedule is a legitimate tool. Used that way, debt is fine. It’s a choice made with eyes open.

The failure mode isn’t the debt. It’s the opacity. Most of the time the bill isn’t on a schedule, isn’t on a list, and isn’t visible to the people deciding whether to take on more. What management sees is the velocity bump. What management doesn’t see is the interest accruing under it. They get used to that velocity, treat it as the new baseline, and ask for more of the same next quarter. By the time the cost surfaces, the team is already three quarters into a habit nobody chose.

The dichotomy only holds inside a window that’s smaller than people think.

The sprinter looks fast. Until they don’t.

For a stretch, the team on the fast pill really does ship more. They skip the upgrade, they skip the test, they push the migration to the next quarter, and the burndown chart looks great. The roadmap moves. Stakeholders are happy.

Then the bill arrives, and it doesn’t arrive politely. It arrives as a CVE that forces a framework upgrade you’ve now deferred three majors of. It arrives as a flaky deploy at 11pm because the deployment scripts haven’t been touched in two years. It arrives as a restore attempt during a real incident that no one has ever actually rehearsed.

Suddenly the team that was sprinting is spending most of its week not breaking. The feature velocity that looked real for a year and change quietly becomes incident velocity. Nothing has changed about the team’s talent or work ethic. The work just shifted from building to surviving. If you keep going down this path long enough, people start throwing around terms like “heat-death” and “rewrite,” only to rinse and repeat, as if this were the inevitable end they were always marching towards.

If you sprint the marathon, it only looks like you’re winning. The clock isn’t done with you when the demo is done.

What it looks like to still be shipping in year two

Walk into the other team’s office at month twenty-four and you’ll see something quieter and calmer. They didn’t ship as much in their first year. They took the framework patches the week they shipped. They wrote the test before they wrote the fix. They rehearsed the restore last quarter, on a normal Tuesday, with nobody yelling.

And now, in year two, they’re still shipping features. Not because they’re heroic. Because nothing is on fire.

The disciplines that look slow from the sideline are the actual source of sustained (and sustainable) pace. Current dependencies don’t show up on a roadmap, but a deferred upgrade does, eventually, as a multi-week project that eats a quarter. An exercised restore looks like time spent doing nothing, until the day it looks like the only reason you still have a business.

It’s a marathon, not a sprint. And the gap visible at month twenty-four only widens from there. The same disciplines that buy you year two are what buy you year five, and year ten, and the conversation we have with clients about apps that are still doing the job in year fifteen.

The cost of going well just dropped. The principle didn’t.

Here’s what’s changed recently, and it’s worth saying out loud.

For a long time, one of the honest objections to the marathon pill was that the disciplined path was expensive. A serious framework upgrade on a long-lived Rails app could be 100 hours of grinding, version-by-version labor. The math sometimes didn’t pencil out, and we said so.

That math is shifting fast. We recently took a Rails 4 app to Rails 8.1 in about ten hours, working alongside an AI coding agent on what would have been a 100-hour project the old way. An order of magnitude. A real share of that recovered time goes right back into the human work that still matters: reviewing what the agent produced, writing the tests it missed, exercising the staging environment by hand. The work that used to be the most expensive line item in the stewardship budget is now one of the cheapest.

That changes the cost of going well. It does not change the principle. The reason to stay current was never that it was cheap. It was that the alternative is more expensive, paid in a currency you don’t see on the invoice.

Going well is going fast

Measured inside a quarter, Steve is right. Pick a pill.

Measured across the life of an application that actually matters to the people who use it (the customer portal that’s been there for a decade, the internal tool that runs operations, the Rails app your team has built its workflow around, the kind a university or a publisher or a hospital depends on for fifteen years), the dichotomy dissolves. The team that stayed current shipped more. The team that exercised the restore had a business to come back to. The team that took the boring patches every Tuesday wasn’t slower. They were the only ones still moving, and still able to find developers who knew how to contribute to their code.

The only way to truly go fast is to go well.

(That’s a paraphrase of a line from Robert C. Martin’s Clean Architecture. The principle is older than the book; the phrasing is his.)

A lot of what we do at Neomind is the work of making the maintenance side of the ledger visible. For decades, we’ve coached teams to put maintenance on the same backlog as features, in language non-technical stakeholders can understand and prioritize. That’s most of what stewardship looks like in practice. The patches and the restores follow from it.

If you’ve got an app you intend to still be running in year ten, we’d love to talk about what stewardship could look like for it.