Slow Down to Speed Up

Skipping the cleanup to hit a date feels fast in the moment, and over a single sprint it often is. The problem is that skipping the test, the small refactor, or the flaky-pipeline fix does not delete that work. It defers the work at interest, and the interest comes back as bugs, rework, and time lost to firefighting. The intuitive read is that maintenance is time not spent shipping, so it must slow you down. Research on delivery performance points the other way: teams that keep their code and pipeline clean tend to ship more often, not less. The recommendation here is to default to a steady, maintenance-inclusive pace, and to treat technical debt as a deliberate, scheduled decision rather than an accident. This is a practice guide for working engineers, junior to senior, who have shipped a feature and then lived with the mess. It covers what debt costs, when a refactor pause pays back, why tests and CI are real work, and how sustainable throughput beats heroic sprints.

A few old ideas circle this claim, and they are worth naming once before moving on. Festina lente, “make haste slowly,” was a favorite maxim of the emperor Augustus: move deliberately to arrive sooner. The training-world line “slow is smooth, smooth is fast” has no firm origin, so treat it as an intuition pump rather than a fact; it does not mean literally slow, it means controlled instead of panicked. And Stephen Covey’s seventh habit, “sharpen the saw,” is the citable version of a popular story about a woodcutter who stops to sharpen the axe. That axe story is often attributed to Abraham Lincoln, though there is no solid evidence he said it, so lean on Covey rather than the quote. The rest of this post leaves the maxims behind and stays on engineering practice.

The rework tax

Ward Cunningham coined “technical debt” in a 1992 experience report, and the metaphor still holds. Shipping first-time code, he wrote, is like going into debt: “A little debt speeds development so long as it is paid back promptly with a rewrite,” and “Every minute spent on not-quite-right code counts as interest on that debt.” The interest is not abstract. A feature that ships with no tests is cheap today. The next three changes near it each risk breaking something, and each fix takes longer than the test would have. That is the rework tax: the share of your week that goes to repairing recently shipped work instead of building the next thing.

Firefighting compounds it. A team that keeps skipping maintenance spends more of each week on incidents, hotfixes, and “why is this slow” investigations. That time is taken straight from the roadmap. In one codebase, a skipped integration test around a payment edge case turned into a string of production fixes over the following weeks. Each one was urgent, and each one interrupted planned work. Writing the test would have been cheap. The interest was not, and it was paid in the worst currency there is: unplanned time.

Not all debt is bad: take it on purpose

The opposite mistake is treating every shortcut as a failure. It is not. Cunningham’s own framing assumed debt is fine if you repay it promptly; the danger is debt that is never repaid. Martin Fowler sharpened this into a quadrant with two axes: debt can be deliberate or inadvertent, and prudent or reckless. Reckless-inadvertent debt, the “what is layering?” kind, is what quietly buries a team. Prudent-deliberate debt is a legitimate tool: you know the clean design, you choose to ship now and handle the consequences, and you write the consequence down.

The practical rule follows from that. The point is not “never take debt.” It is “take it on purpose and repay it on a schedule.” A debt you named, timeboxed, and told the team about is a decision. The same shortcut taken silently, with no plan to return, is just decay with a deadline.

Refactor before you add

When code fights you, the instinct is to add the new feature on top and clean up afterwards. The cleanup rarely comes, because later never has slack. The better order is Kent Beck’s, posted in 2012: “make the change easy, then make the easy change.” Refactor the messy part first so the new code drops in cleanly, then add it. Fowler documents this as preparatory refactoring, and the economics are simple: you pay the cleanup cost once, on code you already have to touch, instead of paying interest on every future change.

This works best in small, continuous steps, not a big-bang rewrite. The rewrite is the debt trap wearing a nicer suit: it ships late, and it reintroduces the old bugs the current code already handles. A lighter habit does more good. If you will touch this code again soon and it fights you, clean the part you touch, and leave it a little better than you found it. On one team, a small rename and a short extraction before starting a feature turned what had looked like a slow, risky change into a quick one, because the feature no longer fought the shape of the code. That is the pause paying back inside the same task.

Tests and CI are part of the product

Tests are what let you move fast without fear. Without them, every change is a gamble on whether something three files away just broke. With them, you refactor and ship on the same day, because the suite tells you the moment you are wrong. Skipping tests under deadline is borrowing at the highest interest rate there is.

The pipeline counts too. Flaky tests, slow builds, and skipped checks are technical debt in their own right, and they tax every commit the whole team makes. A build that fails at random trains people to stop reading failures, and once nobody reads them, a real regression slips through unnoticed. Budget time to fix the pipeline the way you budget time to fix the product, because a red or slow build is a cost paid by everyone, on every push. CI health is a first-class signal, not a chore for a quiet afternoon.

Sustainable pace over heroics

The same logic scales up to how a team spends its weeks. The Agile Manifesto put it plainly in its eighth principle: “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” Extreme Programming seeded the idea with a blunter version. Kent Beck’s book Extreme Programming Explained set a forty-hour week and a rule against working overtime two weeks in a row. The community later reframed it as “sustainable pace,” which captures the nuance better than a fixed number.

A crunch borrows from the next sprint’s capacity at a bad exchange rate. The date gets hit, and then the following weeks go to the bugs the crunch created and the recovery it demands. Worse, repeated heroics teach the team and its stakeholders to expect heroics, so the exception becomes the plan. High output that decays is not speed. It is a loan.

Speed and stability are not a tradeoff

This is where the intuitive objection has to be met head on. If maintenance is time not spent shipping, surely a maintenance-heavy team ships less. The DORA research program, summarized in the book Accelerate, found the opposite. Its four delivery keys are deployment frequency, lead time for changes, change failure rate, and failed-deployment recovery time. The throughput keys correlate with the stability keys rather than trading against them. The teams that deploy often also fail less and recover faster. Speed and stability travel together.

The mechanism is the one already described. Clean code and a trustworthy pipeline are what make frequent, low-risk deploys possible, and frequent low-risk deploys are what keep lead time short. A separate guide on this site works the throughput side of the same coin, reducing lead time from commit to production, and it lands on the same finding: you do not buy speed by sacrificing stability, you get both from the same practices.

When to override

The default is a steady, maintenance-inclusive pace. Three narrow cases justify skipping the cleanup, and they are worth naming so the exception stays an exception.

A throwaway prototype that will be deleted is not worth cleaning; the whole point is to learn and discard. A security or availability hotfix under a live incident should ship now, with the cleanup filed and repaid the same week. And a genuine deadline with a known short-term shortcut can justify prudent, deliberate debt: write it down, schedule the repayment, and tell the team. Everything outside those three is the common case, where the small cleanup now is cheaper than the interest later.

Common pitfalls

• Confusing motion with progress. Rising story points alongside a rising change-failure rate is decay, not speed. Watch outcomes, not point counts.
• The big-bang rewrite. Deferring all cleanup to a future “rewrite quarter” tends to ship late and reintroduce old bugs. Prefer small, continuous refactors.
• Treating tests and CI as optional. Dropping them under deadline is borrowing at the highest rate. The pipeline is part of the product.
• All-or-nothing debt. Believing all debt is bad leads to gold-plating; believing debt is free leads to collapse. Use the quadrant, and take prudent, deliberate debt on purpose.
• Quoting the axe story as fact. It is popular but apocryphal. Hedge it, and cite Covey instead.
• Crunch as the default. Repeated heroics become the expected plan. Keep sustainable pace the norm and crunch a rare, deliberate exception.

What to measure

If a steady pace is an investment, you should be able to see the return. A few signals help, and most cost nothing to start tracking.

• Change failure rate: the share of deploys that cause a failure needing remediation, one of the four DORA keys. Skipped maintenance tends to push it up.
• Lead time for changes and deployment frequency: the throughput keys. A healthy pace should hold or improve these, not trade them away.
• Failed-deployment recovery time: a direct read on firefighting load, which should fall as maintenance rises.
• Rework rate: the share of work that is repairing recently shipped work, a good proxy for the interest you are paying on skipped cleanup.
• Maintenance budget as a share of capacity: naming an explicit slice keeps it from being crowded out. Reserving something like a fifth of capacity is a common team choice, not an industry benchmark, so set it deliberately rather than copying a number.
• CI signal health: build duration and flaky-test count are leading indicators of pipeline debt, visible before that debt reaches production.

Default to a steady, maintenance-inclusive pace, and treat debt as a decision you make on purpose and repay on a schedule. Reach for an override only in the three narrow cases: a throwaway prototype, a live incident, or a real deadline where you name the debt and plan its repayment. The payback shows up over a quarter, not a single sprint, which is the honest communication challenge with stakeholders. The next step is small: pick the one piece of code you keep flinching away from, and clean the part you touch the next time you are in there.

References

• FranklinCovey: The 7 Habits of Highly Effective People (Habit 7, Sharpen the Saw) - Covey’s renewal habit: stop to sharpen the tool so you keep cutting. The sound citation for the framing, in place of the Lincoln quote.
• Ward Cunningham: Explaining the debt metaphor (c2 wiki) - Cunningham in his own words on what the technical-debt metaphor did and did not mean.
• The WyCash Portfolio Management System, OOPSLA ‘92 (ACM) - The 1992 experience report where “technical debt” was coined; primary source.
• Martin Fowler: TechnicalDebtQuadrant - The deliberate/inadvertent and prudent/reckless framing that shows not all debt is equal.
• Martin Fowler: An example of preparatory refactoring - Documents Kent Beck’s “make the change easy, then make the easy change”; refactor before you add.
• Agile Manifesto: Principles behind the Manifesto - Principle 8 on sustainable pace: “maintain a constant pace indefinitely.” Primary source.
• DORA: Software delivery performance metrics (the four keys) - The four keys and the finding that speed and stability are correlated, not a tradeoff.
• Quote Investigator: “spend time sharpening your axe” - Confirms the Lincoln attribution is apocryphal; the earliest matches credit an anonymous woodsman, not Lincoln.
• slow is smooth, smooth is fast (Wiktionary) - Records the phrase’s training-world usage and its uncertain origin; supports treating it as folklore.
• Ron Jeffries: Extreme Programming and sustainable pace - XP’s forty-hour-week practice, later reframed as sustainable pace.
• Accelerate (Forsgren, Humble, Kim) - The research behind DORA; the book-length case that high performers get speed and stability together.