The First Week: Establishing Facts

The First Week: Establishing Facts is the part of a rescue where you are not allowed to have an opinion yet. Its entire job is to convert the five-way question from Chapter 1 into four facts, drawn from three records that already exist, inside five working days.

Key takeaways

• Four facts, and nothing else, in week one: can it be deployed, can it be tested, can the domain logic be located, and can anyone explain a decision. The first three are settled from records. The fourth takes longer than a week and is the whole of Chapter 3.
• Three records carry most of the evidence: the deploy and CI history, the incident record, and the repository's own commit history. What people tell you is a fourth source, and it gets checked against the other three rather than trusted over them.
• Measure the schedule as a distribution rather than as a date. Four of DORA's five delivery metrics are reconstructable from git and CI on a codebase nobody instrumented: change lead time, deployment frequency, change fail rate, failed deployment recovery time.
• Run the claimed test suite and the actual test suite as separate exercises. Clone at the released tag, run it cold, and count what is skipped. The gap between claimed and actual is the most reliable early predictor of what week two costs.
• What leaves the room on day five is a written statement of facts with the verdict deferred and gaps marked as gaps. If the document only works while its author is in the room, it was a pitch.

Read this beside Chapter 1, which defines the five conditions these facts discriminate between, and Chapter 10, which is where deployability gets repaired rather than merely measured. For the discipline of measuring before touching anything, Laravel Optimization Playbook makes the same argument at the level of a single slow request.

The first hour of a rescue is the hour most likely to be wasted, because the instinct is to open the code. Resist it for one more day. The code is the least reliable narrator in the building: it tells you what is true now and nothing about how it got that way, which is the part you were hired to work out.

Ask for read access to four things instead. The repository, with full history and all branches. The CI and deployment system, with its build history intact. The error tracker, however neglected. And whatever passes for an incident record, including the support inbox and the channel where people complained.

Then ask one question of the humans: who has left in the last six months, and when does the next person go. That answer sets the deadline on the only evidence with an expiry date.

Why a week, and not a month?

A diagnostic has to be shorter than the patience of the person paying for it, and on a stalled build that patience is a function of money rather than of temperament. CB Insights, reviewing 431 venture-backed companies that shut down since 2023, found 70% ran out of capital, and noted that running out of capital is almost always the final cause rather than the root problem. On a rescue the same shape applies at a smaller scale. Every week of assessment is a week of burn against a launch, a contract or a raise, and an assessment long enough to be thorough is long enough to become part of the problem it was hired to diagnose.

A week is defensible for a specific reason, not for the roundness of it. The three records that carry the evidence were written already, by the previous team, without knowing you would read them. Nobody has to produce anything new for you. A year of deploy history, incidents and commits is several days of reading, and the marginal fact you learn in week three rarely changes the verdict.

The box also changes your behaviour. An open-ended audit rewards collecting. A five-day audit forces you to stop collecting and start writing, and writing is where opinions get separated from facts.

Four facts, and nothing else

Everything week one produces reduces to four questions. Each one, answered honestly, eliminates or confirms at least two of the five conditions from Chapter 1, and each has evidence that exists independently of anyone's account of it.

Three of those four are settled by reading records. The fourth is settled by talking to people, which is why it runs past a week and carries a deadline you do not control.

Four facts. No verdict yet.

The deploy record is the schedule, stated honestly

Chapter 1 argued that the schedule is usually the actual defect and that its signature is variance rather than slowness. The deploy record is where that argument becomes a measurement, and the useful thing is that it works on a codebase nobody instrumented, because git and CI recorded it by accident.

DORA publishes the definitions to measure against, and the set is now five rather than the four everybody quotes: change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate. Change lead time is the time from a change being committed to version control to it being deployed in production. Change fail rate is the share of deployments needing immediate intervention afterwards.

You will reconstruct approximations of these rather than measure them properly. Approximations are enough. Take the last forty changes that reached production and record the time from merge to deploy for each, which gives a distribution rather than an average. Count production deploys in the last ninety days against merges to the main branch in the same window; a large gap means work is finished and parked, which is the classic undeliverable signature. Then count the deploys followed within a day by a revert, a hotfix, or a commit whose message contains an apology.

Read the distribution, not the mean. Flyvbjerg and Budzier's finding that one IT project in six overruns cost by 200% is a statement about tails, and the tail is where a date dies. Tornhill and Borg found the same shape inside the codebase: low quality code showed 9 times longer maximum issue cycle times, which is what a long-tailed lead-time chart looks like from the inside.

One more thing the deploy record gives you is often the most informative fact of the week. Find the date the cadence collapsed. Weekly, then monthly, then nothing. Something happened in that month: a person left, a decision was taken, a dependency was upgraded. Whatever it was, that is where the story starts.

The test suite you were told about, and the one that runs

Ask about tests and you will be told a number. Coverage is 60%, or there are eleven hundred tests, or the suite is green. Treat all of it as a claim awaiting verification, because in a stalled delivery the test suite is the artifact most likely to have quietly stopped being true.

The measurement is deliberately crude. Clone the repository at the tag running in production, on a machine that has never built this project. Follow the written setup instructions exactly, and time how long it takes to reach a passing suite or a failure. That number is the fact. A codebase that takes two days to build on a clean machine has a maintainability problem no coverage figure compensates for, because every new engineer pays that cost before contributing anything.

Then look at what the green actually covers. A suite goes green in two ways and one of them is by deletion, so count the skipped and excluded tests. Look for tests that assert nothing, tests wrapped in a try that swallows the failure, and directories excluded in a config file with a comment saying "temporarily". Then ask which of the paths that move money, change permissions, or write to a customer record have a test at all. Coverage percentage is close to useless here. Coverage of the six things the business cannot survive being wrong is the fact worth writing down.

That gap is not only a technical finding. It tells you how the previous team was managed, and how much of what you are told this week will need checking.

The incident record is the only witness with no stake

Everybody you interview this week has an account of what happened, and every account is shaped by what it costs the person giving it. The incident record is different, because it was written before anyone knew you were coming.

Google's SRE book defines a postmortem as "a written record of an incident, its impact, the actions taken to mitigate or resolve it, the root cause(s), and the follow-up actions to prevent the incident from recurring", and defines the triggers that should produce one: user-visible downtime past a threshold, data loss of any amount, an on-call engineer intervening manually, and a failure discovered by a human rather than by monitoring. On a healthy delivery you can read those documents and learn the system's real failure modes in an afternoon.

On a stalled delivery there are usually no postmortems, and their absence is a fact rather than a dead end. It says the organisation was absorbing failure instead of learning from it, which predicts the same incident is still happening. So you rebuild the record from what people wrote while frightened: the support inbox, the channel where somebody said the site is down again, the error tracker's oldest unresolved issue, the manual database fix documented in a message rather than in a migration.

Two questions to that record. Which failure has recurred most, and what is the manual step someone performs to recover from it? The second one matters more than it looks. A recurring manual recovery is a known defect the organisation has decided to pay a person to absorb, and it is usually the cheapest thing you will fix all quarter.

Reading the repository as a witness statement

The repository holds two documents. One is the code, which nobody should read yet. The other is the history, which is a dated account of what was hard, written involuntarily by everyone who worked here.

Tornhill and Borg's study is useful precisely because their method was version control mining combined with issue data across 39 production codebases, rather than static inspection of the source. The signal is behavioural. A file's change frequency, crossed with its size or complexity, tells you where the cost actually lives, and it will not be where an architecture diagram suggests.

The practical version takes about an hour. Rank every file by number of commits touching it in the last year. Take the top twenty and sort them by size. The files that are both large and constantly changed are where the next six months of budget will go if nothing changes, and they are also where you will find the domain logic, because that is the part the business kept asking to alter.

Then read the messages on those files rather than the diffs. Look for the same word appearing three times: fix, again, revert, actually. A file with four commits saying "fix rounding" over eight months is telling you that the rounding rule is not understood, not that the developer was careless. That distinction is the difference between a codebase that is unmaintainable and one that is mis-scoped, which is the single most consequential call from Chapter 1.

Look at authorship too. If one person wrote 70% of the hot files and left in March, you have located both the domain logic and the theory that has gone missing with it.

What leaves the room on day five

The deliverable of week one is a document, and its most important property is that it works when you are not there.

It states the four facts with evidence attached, so each claim can be checked without asking you. It gives the lead-time distribution and the deploy cadence as numbers, with the window they were measured over. It names the hot files. It records the recurring incident and its manual recovery step. It lists what could not be established and why, because a gap presented as a gap is evidence and a gap papered over is a liability. And it states the dominant condition from Chapter 1 with the reasoning behind it.

It does not contain a recommendation about rewriting. That decision needs the fourth fact, and the fourth fact is not available yet.

Withholding it is not modesty. A verdict delivered on day five, before anyone has tried to explain a single non-obvious decision, is a verdict formed from records alone, and records are exactly what Naur argues cannot carry the most important design ideas. It would be a preference wearing evidence.

The document should also be genuinely yours. Take it to another vendor. If its facts stop being true in a different room, they were never facts.

Chapter summary

Week one produces four facts and defers every opinion. Can it be deployed, which is settled from CI and deploy history and which gates every repair that follows. Can it be tested, which is settled by a cold clone at the released tag and by counting what the green build is skipping rather than by reading a coverage number. Can the domain logic be located, which is settled from the schema, the write paths and the integrations. And can anyone explain a decision, which is settled by people, cannot be finished inside a week, and carries the only deadline you do not control. Three records supply almost all of it: the deploy record, which is the schedule stated honestly and yields a distribution rather than a date; the incident record, the only witness with no stake, whose absence is itself a finding; and the repository history, which ranks the system by where change actually costs. Interviews get checked against those three rather than trusted above them. The week is boxed because the money is burning and because a box forces writing. On day five one document leaves the room, verdict deferred, gaps marked, evidence attached.

The fourth fact is still open, and it is the expensive one. Chapter 3 takes it on directly: reading a codebase you did not write, why the theory behind it is not recoverable from the text alone, and what to do in the weeks before the last person who understood it finishes their notice period.