Stability Before Features

Stability Before Features is the rule that an unstable system cannot be forecast, and a delivery that cannot be forecast cannot be renegotiated. It is the first repair work in this book, and it is deliberately narrow. Stability here means the system stops surprising you, not that it becomes good.

Key takeaways

• Stabilise first because instability destroys estimates before it destroys uptime. A team that cannot say when something will be done has nothing to renegotiate with, which makes this chapter a precondition for Chapter 7 rather than a preference.
• An indefinite feature freeze fails politically before it fails technically. It has no stated end, so it gets overruled by the first customer commitment, and the overruling is usually correct.
• Replace the freeze with a measured rate and a budget. DORA's change fail rate and failed deployment recovery time are the two numbers that decide how much repair the week can afford.
• Fix irreversible harm first, in this order: data corruption, then money movement, then availability, then noise, then performance. The ordering principle is what cannot be undone, not what is loudest.
• Alert noise is a stability defect with an owner problem attached. A team that has learned to ignore alerts has lost the ability to detect the next real one, and no amount of repair restores that until the noise goes.

Read this beside Chapter 4, which decided what the fate of each component is, and Chapter 6, which builds the test net that makes deeper repair safe. Chapter 10 returns to deployment itself, once there is something worth deploying.

The Thursday deploy takes down checkout for nineteen minutes. It is the third incident this month, and by the time the room has recovered, the argument has moved on from what broke to whether the team should be shipping at all. Someone proposes a freeze until the system is stable. Someone else points out that two enterprise customers are waiting on a feature promised for the quarter.

Both are right, which is why the argument recurs weekly and never resolves. The missing piece is not resolve. It is a number.

Why stability comes before everything else in the repair order

The obvious argument is reliability, and it is the weaker one. Nineteen minutes of downtime is survivable for most businesses, and everyone in the room knows it.

The real cost is forecasting. Tornhill and Borg, studying 39 proprietary production codebases in 2022, found that low quality code carried maximum issue cycle times around nine times longer than high quality code. Their finding about the tail matters more than their finding about the average, because a team quoting a date is implicitly quoting a distribution. When the tail is that long, every estimate the team gives is a guess dressed as a commitment, and the business learns to discount all of them equally.

That is the mechanism by which a technical problem becomes a trust problem. It also explains why stabilising first is not a technical preference. Chapter 7 asks the business to accept a new plan. A team whose last four dates were wrong has nothing to offer in that conversation, and no amount of sincerity substitutes for a forecast that holds.

Martin Fowler put the economics of this in May 2019: internal quality pays back in weeks rather than years, and there is almost no runway on which trading quality for speed makes sense. On a stalled delivery the runway is already behind you.

An indefinite feature freeze fails before it starts

The instrument people reach for is a freeze. It is the wrong instrument, and the reason is political rather than technical.

A freeze with no stated end is a promise that the team will decide, at an unspecified future point, when the business may have its roadmap back. No commercial organisation accepts that for long. The freeze holds for two weeks, until an enterprise customer escalates, and then it is overruled. The overruling is not a failure of discipline by the business. It is the correct response to an open ended demand with no exit condition.

What follows is worse than not having frozen. The team has spent its credibility on a rule that was broken, so the next proposal starts from a deficit. Meanwhile the repair work that did happen is unattributed, because nobody measured the state before it started.

A freeze can work in exactly one form: short, dated, and scoped to a named condition. Five working days, ending when the recurring incident stops recurring, with the shipping schedule after it already agreed. That is not a freeze so much as a sprint with an unusual goal, which is why it survives contact with a customer escalation.

Measure instability before you claim to be reducing it

You cannot fund repair against a feeling. Two of DORA's metrics carry this argument, and their current definitions matter because the set was revised. As of the guidance published on 5 January 2026, DORA describes five metrics rather than the original four: change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate.

Change fail rate is the ratio of deployments that require immediate intervention. Deployment rework rate is the ratio of deployments that were unplanned and happened because of a production incident. On a stalled delivery the second number is the one that shocks people, because it makes visible the work nobody scheduled: the hotfix on Friday evening, the config change to stop the alerts, the redeploy of last week's build.

Take a four-week baseline from the deploy history you already reconstructed in the first week. Not an average, a list. Each deployment, whether it required intervention, and how long recovery took. The list is more persuasive than the ratio, because a founder who has been told "reliability is poor" for a month can read eleven rows and see it.

Then publish the number weekly, in the same place, whether it improves or not. A metric that appears only when it flatters the team is not a metric.

Error budgets turn the argument into arithmetic

Once instability is measured, the question of how much repair to fund has an answer that does not depend on who is more persuasive in the meeting.

Google's SRE practice states the mechanism plainly in Embracing Risk: an objective is set, actual performance is measured, and the difference between the two is the budget of unreliability remaining for the period. While budget remains, releases proceed. When it is spent, releases slow until resilience improves.

Adapting that to a rescue takes one change. A stalled delivery usually has no service level objective, no error budget policy, and no appetite to build either this quarter. So set the objective against the team's own recent history rather than against an aspiration: this month's change fail rate, halved. It is arbitrary as a target and unarguable as a direction, and it produces the same effect, which is that the split between repair and delivery stops being a matter of opinion.

In my experience the political value of this exceeds the technical value. An error budget gives the business a lever it can actually pull. Spending more of the budget on features is allowed, it is stated, and its cost is visible in advance. That is a very different conversation from being told no by an engineer who has already lost the last three of these arguments.

Stop the bleeding in the order the harm becomes permanent

Triage order is decided by reversibility, not by volume of complaint.

Data corruption first, always. A system writing wrong data is destroying the only asset that cannot be rebuilt from a backup of itself, and every day of delay widens the range of records that will need reconciling. Money movement second, for the same reason with a legal edge: a double charge is reversible for a week and expensive forever after. Availability third, because outages are loud, bounded and recoverable. Alert noise fourth. Performance last, unless slowness is causing one of the first three.

Alert noise deserves its place in that list rather than a footnote. A team that has learned to ignore its alerts has lost detection, which means the next real incident will be discovered by a customer. Fixing that is unglamorous: delete the alerts that have never once corresponded to action, route what remains to a person by name, and require that every page produce either a fix or the deletion of that alert. Google's postmortem practice supplies the discipline that makes this stick, which is that the review is blameless and its output is an action with an owner rather than a description of what happened.

One caution about the ordering. It is the order to repair in, not the order to communicate in. The founder is being asked about availability, because that is what customers report, and a repair plan that leads with data integrity needs a sentence explaining why the invisible thing is going first.

When the instability is not in your system

A share of the incidents on a stalled delivery originate somewhere you do not control. A payment provider that times out under load. A partner API that changes a response shape without telling anyone. A queue in a managed service that silently drops messages above a size nobody documented.

Teams under pressure treat these as excuses, and record them that way in the incident log: third party, not our fault, no action. That is how the same outage happens four times. The provider's reliability is not your responsibility. Your system's response to it is, entirely, and it is usually the cheaper thing to fix.

Three repairs cover most of it. Make the call idempotent, so that a retry cannot charge twice or send two emails. Bound the wait, so that one slow dependency cannot consume every worker you have and turn a partner's degradation into your outage. Then decide the behaviour on failure explicitly, and write it down: queue it, fail the request, or serve a stale result. Most stalled systems have never made that third decision, so the behaviour on failure is whatever the framework does by default, which is usually to hang.

There is a diagnostic buried in this. If a majority of your incidents are triggered externally and none of them have an owned response, the dominant condition from Chapter 1 is probably not unstable at all. It is unowned, and no amount of repair inside the codebase will move it.

Run two lanes, not one

The practical form of all this is a week with two lanes: repair and delivery, both funded, with the split set by the measured rate rather than by negotiation.

At the beginning, repair takes most of the week. As the change fail rate falls, the split moves toward delivery, and it moves on the published number rather than on a date. The delivery lane is never zero, and that is the part teams get wrong. Shipping something small every week is what keeps the rescue politically alive, gives the business visible progress it can report upward, and proves the deployment path still works. A pipeline that goes four weeks without a release is a pipeline nobody knows is broken.

Keep the two lanes visibly separate in whatever tracker exists. Repair work logged as delivery work makes both invisible: the business sees a roadmap that has slowed for no stated reason, and the team cannot show what the repair bought. Separate lanes turn the same effort into an argument you can win in Chapter 7.

Chapter summary

Stability comes first because instability destroys forecasting before it destroys uptime, and Tornhill and Borg's finding on maximum issue cycle times in low quality code is the mechanism: when the tail is nine times longer, every date the team quotes is a guess and the business correctly stops believing all of them. The instrument that fails is the indefinite feature freeze, which has no exit condition, gets overruled by the first customer escalation, and costs the team the credibility it will need later. What replaces it is measurement, then arithmetic. Baseline the deploy history into a list rather than a ratio, publish DORA's change fail rate and deployment rework rate weekly under their current definitions, and set an objective against the team's own recent history so that an error budget can decide how much repair the week funds. Triage by reversibility: data corruption, then money movement, then availability, then alert noise, then performance, with noise counted as a detection defect rather than an annoyance and every page required to produce a fix or a deletion. Incidents that originate outside your system still belong to you at the point of response, and idempotency, a bounded wait and a written failure behaviour cover most of them. Then run the week in two lanes, repair and delivery, both non-zero, with the split moving on the published number. The delivery lane is not a concession. It is what keeps the rescue funded and proves the release path still works.

The system now surprises you less often, which means it is safe to make it better. Chapter 6 is Building a Test Safety Net Retroactively: where to put the first tests when there are none, why characterisation tests pin behaviour rather than assert correctness, and how to buy the ability to change the paths the business depends on without asking anyone to trust you.