What "Broken" Usually Means

What "Broken" Usually Means is the triage question a rescue answers before it answers anything else: which kind of broken is this one? There are five. They do not share a first move, and getting the label right is worth more money than any decision you will later make about the architecture.

Key takeaways

• Broken is five conditions wearing one word: unstable, undeliverable, unmaintainable, unowned, and mis-scoped. Name the dominant one before proposing anything at all.
• The label picks the first move. Unstable is answered with an incident practice, undeliverable with a schedule renegotiation, unmaintainable with a test net, unowned with an interview, mis-scoped with a conversation the business has to be in. Start on the wrong one and you spend a month proving nothing.
• Most deliveries that arrive described as a technical failure are a schedule failure that grew a technical symptom. Flyvbjerg and Budzier measured a 27% mean cost overrun across 1,471 IT projects, with one project in six overrunning cost by 200% and schedule by almost 70%.
• What destroys a date is variance, not slowness. Tornhill and Borg measured 9 times longer maximum issue cycle times in low quality code, which is the difference between a delivery that is late and a delivery that cannot be forecast at all.
• Nobody currently in the room can hand you the label, including whoever you hire to find it. Each party has a reason to prefer a different answer, so the label has to come from evidence gathered in a fixed order and written down.

Read this beside Chapter 2, which turns the label into a week of evidence, and Chapter 6, which turns that evidence into a rewrite-or-repair decision. If the symptom in front of you looks structural rather than operational, System Design for Developers is the companion argument.

The message is usually short and it usually arrives on a bad day. Some version of this: the app is broken, the agency has gone quiet, we launch in six weeks, can you look at it.

Four of those clauses are load-bearing. One of them is about software.

I am not going to open this book with a client story. There is a version of this chapter that starts with a fintech in month eleven of a four-month build, a figure attached to what it cost, and a satisfying turnaround at the end, and that version would persuade you more than this one. It would also be a claim you have no way to check. Rescue work is confidential in precisely the way that makes case studies either unpublishable or invented, so what you get here is the method and the reasoning that produces it. Hold me to those instead.

Five conditions that all get called broken

"Broken" is a report of a feeling. It is accurate about the feeling and tells you almost nothing about the fault. The useful move is to treat the word as a symptom, then sort it into one of five conditions, because each of the five is repaired by a different first action and each punishes a different mistake.

The five are not a taxonomy I invented for elegance. They are the five distinct things a delivery can lose: the ability to run reliably, the ability to be released, the ability to absorb change, the ability to be explained, and the ability to be the right product. A system can lose any one of them while keeping the other four.

Most deliveries arrive carrying two or three of these at once, which is why the word "broken" survives as a description. A codebase nobody can explain becomes expensive to change, and a codebase expensive to change stops being released, and a system that stops being released accumulates a batch of untested changes that eventually goes out together and takes production with it. The conditions compose in that direction, and the compounding runs one way.

That ordering is the useful part. Name the dominant condition. The others get their turn.

Why the label decides the money

The expensive error in a rescue is almost never a wrong opinion about the architecture. It is a wrong opinion about the category, because the category chooses which month you spend and which month you do not.

Consider the two labels most often confused. Unmaintainable and mis-scoped present identically from the outside: work goes in, very little comes out, and everyone is tired. The repairs could not be less alike. Unmaintainable is answered inside the codebase over weeks, with tests and seams and a slower release cadence that gets faster later. Mis-scoped is answered in a room with the business in about two hours, by cutting the half of the roadmap nobody has needed since the market moved. One of those costs a quarter. The other costs an afternoon and some discomfort.

Get that pair backwards in the direction of unmaintainable and you have bought a quarter of engineering to deliver a product that was already wrong. Get it backwards the other way and you cut scope on a system that will fail on the remaining half anyway.

My reading, offered as judgement rather than measurement, is that the category defaults toward unmaintainable more often than the evidence supports, because unmaintainable is the label that justifies the largest piece of work. It is also the most flattering label for everyone present. Nobody has to have made a bad decision for code to have become hard to change.

The schedule is usually the actual defect

Flyvbjerg and Budzier analysed 1,471 IT projects and found a mean cost overrun of 27%. The mean is the least interesting number in that paper. What matters is that one project in six was what they call a black swan, overrunning cost by 200% on average and schedule by almost 70%. Cost overrun on IT projects is fat-tailed, which means a project running 30% over is not a slightly worse version of average. It is a project that has entered a different regime, and the ordinary planning instinct of adding a contingency percentage does not describe that regime at all.

The mechanism underneath the tail is variance, and variance has a measurable source. Tornhill and Borg studied 39 proprietary production codebases and 30,737 files, and found that low quality code carried 15 times more defects, took 124% more time to resolve an issue on average, and, most usefully for a rescue, showed 9 times longer maximum cycle times. That last figure is the one to keep. A team whose changes usually take three days and occasionally take six weeks cannot commit to a date, however fast its average looks. A team at five days with a tight spread can.

So when a founder tells me the build is broken and points at the code, the first thing I want is not the code. It is the distribution of how long the last forty changes took to reach production. If that distribution has a long right tail, the schedule was never real, and every date since has been a guess dressed as a commitment.

This is also why the reflex of adding developers usually fails. Brooks named the effect in The Mythical Man-Month: adding people to a late project makes it later. The reason is mechanical rather than moral. New people consume the attention of the few who still hold the system in their heads, which is the scarcest resource in the building and the one the schedule already depends on.

You cannot plan against a mean. You plan against a tail.

Unowned is a different kind of broken

The most precise definition of a broken codebase I know was written in 1985. Peter Naur argued that a program is not really the text; the program is a theory held by the people who built it, and the text is a lossy record of that theory. From which he draws a consequence that should be read slowly by anyone about to take over a codebase: "The death of a program happens when the programmer team possessing its theory is dissolved."

Naur is explicit that a dead program keeps working. "A dead program may continue to be used for execution in a computer and to produce useful results. The actual state of death becomes visible when demands for modifications of the program cannot be intelligently answered."

That is unowned, stated better than I can state it. The system passes its tests, serves its traffic, and is dead, because the fault is in the organisation rather than in the artifact. It gives you a field test that takes ten minutes. Pick one non-obvious decision in the system, something with an odd shape, and ask why it is like that. If nobody can answer, and the answer is not in the repository either, you are looking at a dead program regardless of how green the build is. Chapter 3 is about whether it can be revived.

What changes when most of the code was generated

A codebase assembled largely by AI tooling is a genuinely new shape of broken, and the rescue category has not caught up with it.

Two measurements frame it. Veracode tested over 100 large language models across Java, Python, C# and JavaScript and found 45% of generated samples failed security tests by introducing OWASP Top 10 vulnerabilities, with Java at 72% and cross-site scripting undefended in 86% of the relevant samples. Their finding about trend is the one that matters here: syntactic correctness improved with model capability and security performance stayed flat. Separately, DORA's 2025 report, drawing on nearly 5,000 respondents, found AI adoption now relates positively to delivery throughput and still relates negatively to delivery stability, and framed the whole thing as amplification: "AI doesn't fix a team; it amplifies what's already there."

Put those together with the taxonomy and the diagnosis usually falls out cleanly. Generated codebases are rarely unmaintainable in the classic sense. They are often tidy, consistent and idiomatic. They arrive unowned and mis-scoped at the same time, with an undefended security posture and no evaluation of whether the output is correct.

Unowned is the strange part. In a conventional rescue, the theory existed once and dispersed, so there is someone to interview. Here the theory was never built by anyone. Nobody is withholding it and nobody has forgotten it. It does not exist.

Generated code is not old code. It is new code with no witnesses.

Why can nobody in the room tell you which one it is?

Ask four parties which of the five conditions this is, and you will get four answers, each sincere and each shaped by what the answer costs the person giving it.

The incumbent vendor needs it to be mis-scoped, because then the dates slipped for reasons upstream of them. The founder often needs it to be unstable or unmaintainable, because those labels mean the money was not wasted so much as undermined. The engineers inside the build tend to say unowned or undeliverable, because both point at decisions made above their heads. And the rescuer has an interest in unmaintainable, because that is the label attached to the largest engagement anyone is going to sign.

None of that is cynicism about the people. It is the ordinary structure of a situation where the diagnosis and the invoice are produced by the same party. I sell repair work and I sell builds, so the incentive applies to me as directly as to anyone on the list, and the only honest response I know is to make the reasoning inspectable rather than to claim I am above it. Read the argument, not the recommendation.

Which leads to the practical point. The label has to be produced by evidence collected in a fixed order, written down, and portable enough to survive being carried to a different vendor. If a verdict is only true while its author is in the room, it was a sales position. The four facts in the next chapter are things you can establish yourself, with access to the repository and about a week. You should be able to reach the label without me, and be able to check mine against yours.

Chapter summary

Broken is five conditions with one name, and the five do not share a repair. Unstable systems fail in front of customers and want an incident practice. Undeliverable systems never arrive and want the deploy record measured and the schedule renegotiated before anyone touches the design. Unmaintainable systems absorb change badly and want a test net around the paths the business depends on. Unowned systems run correctly and cannot be explained, which by Naur's definition means the program is dead and the question is revival. Mis-scoped systems work and are not the product, and are settled by the business rather than by engineering. Most deliveries carry two or three at once, and they compound in one direction: unexplained becomes expensive, expensive stops being released, unreleased becomes unstable. The label decides which month you spend, so it is worth more than any architectural opinion formed in the same week. Schedule failure is the most common root, and its signature is variance rather than slowness: fat-tailed cost overruns in Flyvbjerg and Budzier, 9 times longer maximum cycle times in Tornhill and Borg. Generated codebases arrive unowned and mis-scoped with a flat security posture and no witnesses to interview. And nobody in the room, including the person you hire, can hand you the label for free.

The next chapter is the week that produces it. Chapter 2 fixes the questions at four, fixes the sources of evidence at three, and fixes the deadline at five days, because a diagnosis that takes a month is hard to tell apart from the problem it was hired to solve, and the money is burning the whole time. CB Insights found that of 431 venture-backed companies that shut down since 2023, 70% ran out of capital. On a stalled build, the clock is not a metaphor.