The Week Nothing Was Added

Objectives

• Remove anything that existed only because it had once been needed.
• Leave no half-removed system behind — a thing is either gone or kept.
• Write down the reason for each removal at the time, not afterwards.

Development Process

Removal work is harder to justify than building because it produces no screenshot. The method used was simple: list everything that had not been touched in a month, then for each item ask what would break if it disappeared. Anything that produced a vague answer was investigated rather than kept, because "something might use it" is how dead systems survive.

Challenges

Two of the items had partial dependents — code that referenced them without needing them. Deleting the item would have left the dependent broken; leaving the item would have preserved something nothing actually used. Both were resolved by removing the reference first and the item second, in that order, so the tree was never in a state that could not boot.

Solutions

Each removal was made in its own step, with its own verification, and its own note. Batched deletions are faster to perform and impossible to review, and reviewing them is the only reason to write them down at all.

Decisions

• A system is removed in full or not at all. Half-removed systems are worse than kept ones, because they look finished.
• Data is backed up before it is dropped, even when the data has no value, because the judgement that it has no value is the thing most likely to be wrong.
• Every removal gets a written reason at the time it is made.

Revision History

Timeline