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. The recommendation here is to default to a steady, maintenance-inclusive pace, and to make every piece of technical debt a deliberate decision with a repayment date on the calendar.

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; it asks for control in place of panic, and says nothing about literal speed. 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 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 paid in unplanned time.

Taking debt 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: take debt on purpose and repay it on a schedule.

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. The big-bang 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.

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.

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. Put CI health on the board as a first-class signal and schedule the work that keeps it green.

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.

The DORA correlation#

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: the teams that deploy often also fail less and recover faster.

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: the same practices buy you both.

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: do the small cleanup now.

Where the discipline breaks down#

Rising story points next to a rising change-failure rate is a warning sign: the count is going up, but the work behind it is getting worse. Change-failure rate and the other DORA measures catch this; story-point totals do not. Treating tests and CI as optional under deadline pressure is the same mistake in a different spot. The pipeline is part of the product, and a tight calendar does not change that.

Use the quadrant, and take prudent, deliberate debt on purpose. Repeated heroics create the same trap at the team level. Everyone learns to expect a crunch.

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 both.
• 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 rather than an industry benchmark, so set it deliberately instead of copying a number.
• CI signal health: build duration and flaky-test count are leading indicators of pipeline debt, visible before that debt reaches production.

The default holds outside those three cases, and payback tends to show up over a quarter, well beyond a single sprint. A practical next step is cleaning the piece of code you already keep avoiding, the next time you are in there.

References#

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