Greenfield Velocity Illusion

Three months into a rebuild the demo is impressive. The new service is clean, the tests are fast, the team is happy, and the incremental re-architecture team next door has spent the same quarter adding a routing facade and extracting one unglamorous read path. Everyone in the room draws the obvious conclusion.

The conclusion is wrong, and the reason is not that the rebuild team is fooling anyone. The rebuild is genuinely faster, because it is running with the constraints switched off: no users, no real input data, no backward compatibility, no production incidents, no obligation to keep anything working while it changes. Those constraints are most of the cost of the system, and deferring them is not the same as removing them.

This is an estimation error with a consistent sign. It is why rewrite estimates are wrong in the same direction across organisations, industries and decades.

Why it matters

The illusion is dangerous specifically because it produces evidence — a working demo — at the moment a funding decision is made. A sponsor comparing "a working new policy engine" against "a facade and one extracted read path" is not being irrational; they are being shown the wrong measurement.

The consequence is that the crossover, where the incremental approach overtakes, typically arrives somewhere in the 6-to-12-month range, which is after the point where cancelling the rebuild has become politically impossible. The programme then continues past the moment its own evidence turned, and the remaining work is the part nobody estimated.

Implementation patterns

Counter-measures are about what you measure, not about which approach you pick:

• Compare progress on the hardest slice, never on feature count. Require the rebuild to process the worst real input — the oldest records, the malformed ones, the tenant with the peculiar configuration — before any velocity claim is accepted.
• Run real production traffic through the rebuild as shadow input from the first month, serving the old response. This surfaces the deferred cost early, when it is still information rather than a crisis.
• Write the back-loaded list explicitly at the start: history migration, integrations, undocumented behaviours, operational maturity, the long tail of input malformation. Estimate each one, and re-estimate at every gate.
• Track "percentage of real production traffic served" as the progress metric instead of "percentage of features built". It is the only one that cannot be front-loaded.
• Set a kill criterion with a date before the money is committed, because it cannot be set credibly afterwards.

Industry example

The best-documented instances of this are the large rewrites that organisations have written about afterwards, and the common shape is consistent: an early phase where everything goes well, a long middle where the real inputs and integrations arrive, and a decision point that has already passed. The pattern is also what makes incremental decomposition the default recommendation in the industry literature since the late 1990s — not because rewriting is always wrong, but because its cost profile is the one humans estimate worst.

A concrete test that works in production: when a team in month four says "we are 70% done", ask what fraction of live traffic the new system has ever handled. If the answer is zero, the 70% describes the front-loaded half.

Failure scenarios

• The feature-parity gate. Parity is measured against everything the old system does, including its bugs, so the finish line recedes as the old system keeps changing.
• The legacy freeze. Freezing the old system to "avoid wasted effort" either blocks the business for the duration or quietly breaks, after which every change is built twice and the rebuild never converges.
• History migration discovered late. Twenty years of accumulated malformation is found in month fourteen, and it is a project rather than a task.
• Operational immaturity at cutover. The old system earned its runbooks and alerts through a decade of incidents; the new one goes live having had none, and its first month is the first month of that decade.
• The sponsor changes. Long programmes outlive their champions, and the replacement inherits a cost with no memory of the promise.

Trade-offs

Taking the illusion seriously costs something real. Shadow traffic from month one means building a comparison harness and a routing point before any feature work, typically on the order of 3 to 6 weeks with no visible output, and it makes the rebuild look slower in exactly the period when it is being judged. The team will experience this as bureaucracy.

What it buys is that the estimate stops being systematically wrong, and that the decision to continue or stop is taken while stopping is still affordable. You are paying weeks at the front to avoid discovering the truth after the point of no return.

When not to use it

The caution does not apply to genuinely small systems. If the component is on the order of 20,000 lines, has one consumer you can name, and the team has read all of it, the deferred costs are small enough that the front-loaded estimate is roughly right, and building a comparison harness is more machinery than the risk justifies. Rewrite it and cut over.

Nor should it be used as a blanket argument against rebuilding. When the old system's constraint is something incremental change cannot reach — a data model that cannot express what the business now requires — rebuild is correct, and the right response to the illusion is a better estimate rather than a veto.

Interview question

Q: Two teams are four months in: one rebuilding your billing engine from scratch with a working demo, one re-architecting it incrementally with a facade and one extracted read path. The sponsor wants to cancel the second team and fund the first. What do you say, and what single measurement would you ask for before the decision?

What a strong answer covers: that the rebuild's speed is real and comes from deferred constraints rather than from better engineering · the specific deferred items and why they are back-loaded · the measurement that cuts through it, namely the fraction of real production traffic the new system has served and whether it has met the worst real input · that this is an estimation error with a consistent sign, not a judgement about either team · and the conditions under which the sponsor would nevertheless be right.

Quick check

Quiz: A rebuild is visibly outpacing an incremental migration at month three. What is the most likely explanation, and what would you measure instead of features? The rebuild has deferred the real constraints — live inputs, integrations, history, operations — so measure the share of real production traffic it has actually served.

Flashcard: Why do rewrite estimates fail in the same direction every time? — Because the early work is the unconstrained part and the deferred work is the expensive part, so progress is front-loaded while cost is back-loaded, and the crossover usually arrives after cancelling has become politically impossible.