Before a team rewrites a working single-machine data job, which two costs are routinely left out of the comparison?

## Two numbers that never reach the slide When a data job outgrows the way it is currently written, the comparison that gets made is usually between *the job as it is today* and *the job as we imagine it after the rewrite*. Two costs are missing from that comparison almost every time, and they push in opposite directions. The first is the price of simply running the same program on **a machine several sizes larger** — renting more memory and more cores on one box, priced per hour — set against the engineering days a rewrite actually consumes. The second is the **standing cost of two implementations of the same logic**, which begins the day the second one works and never ends while both exist. ## Pricing the larger machine honestly The reason this number is missing is rarely that it is hard; it is that nobody looks it up. When you do, three things usually change the picture: - **Rent is charged for the time you use it.** A job that runs for ninety minutes each night uses roughly forty-five hours a month. The relevant figure is the hourly price times the hours actually consumed, not a headline monthly rate for a machine left running. - **The step that failed sets the size, not the dataset.** The measurement that names the peak at a particular step tells you how much headroom is needed. Sizing to the whole dataset when one step's peak was the problem buys a much bigger machine than the situation requires. - **There is a ceiling, and it is worth knowing where it is.** Rentable sizes stop somewhere. A larger machine that buys eighteen months of room is a very different proposition from one that buys six weeks, and which of those it is can be worked out from what the measurement says rather than guessed. None of this makes the larger machine the answer. It makes it a **priced option** rather than an unpriced one, which is the only state in which a comparison means anything. ## What a rewrite actually costs The symmetric failure is to price a rewrite as the time to write the new code. The honest figure includes: 1. **Writing it** — usually the only part estimated, and usually the smaller part. 2. **Proving it produces the same answers** — running both over the same inputs and reconciling the outputs, including the rows where they legitimately differ and the rows where the original was quietly wrong. 3. **Rebuilding the surroundings** — the scheduling, the alerting, the failure handling and the operational habits that the original accumulated over years and that nobody wrote down. 4. **The learning curve** — the first months during which the team is slower at the new thing than it was at the old thing. The dangerous property of these four is that only the first is visible when the plan is written. ## The standing cost of two implementations This is the cost that is genuinely permanent, and it is worth stating plainly: **from the moment a second implementation of the same logic exists, that logic has to be changed twice and the two have to be made to agree.** | what happens | with one implementation | with two | |---|---|---| | A rule changes | edited once, deployed once | edited twice, reviewed twice, deployed twice, and the two edits must mean the same thing | | The outputs disagree | cannot happen | somebody must decide which one is right, and that person needs both in their head | | A new person joins | learns one program | learns two, plus the differences that are deliberate and the ones that are accidents | | One is retired | not applicable | requires a decision and a dated plan, which is exactly what tends not to happen | The reconciliation is the expensive part, because it is not a task with an end. Two programs computing the same number from the same input diverge for boring reasons — a rounding difference, a different disposition for absent values, one of them dropping a record the other kept — and each divergence costs a person a day to adjudicate and often produces no change to either program. ## What varies Not every second implementation carries the full standing cost. Where it is created **deliberately and temporarily**, with a written date for retiring the original and someone accountable for that date, it is a migration and the cost is bounded. Where it is created as a rewrite that 'we'll switch over once we trust it', the original tends to survive indefinitely as an unfunded fallback, and the standing cost becomes permanent by default. The difference between those two outcomes is a retirement date and an owner, not a technical property. ## What to write down Before either conversation begins, three things should be on paper: the hourly price of the larger machine multiplied by the hours the job genuinely runs; the engineering days for all four components of the rewrite, not just the first; and an explicit statement of whether a second implementation will exist temporarily, with a date, or indefinitely. Any comparison made without those three is a comparison between a number and a feeling.