2026-10-20 · Leading projects and teams
Estimating effort when code is no longer the bottleneck
A client asked for an estimate for two steps, with 14 concrete questions. Before counting days I measured — and found a problem that changed the plan.
The subject was a data export: first run it reliably, then move it into a new service. The 14 questions ranged from latency and load tests to deletions and the data schema.
Measure first
Two read-only investigations ran in parallel: measurements from five days of production logs — run times, time per customer, delay from order to file — and an analysis of the code of three systems against each question.
Something more important than any estimate came out of it: the export kept crashing out of memory, because a large feed was assembled in memory as one single string. That was fixed first. “Speeding up” a system that crashes anyway would have been the wrong first step.
Then the architecture
There were three options: a file as before, pushing each vehicle into the portal, or the portal pulling from the new service. Two AI models independently landed on pull: it reuses the already working “changes since lastchange” logic and matches the plan to move the other file feeds to pull as well. Push needs a new write path plus reconciliation; the file preserves the old scheme. I rejected work on speeding up the old exporter as throwaway work.
Estimate by the bottleneck
With an AI assistant, code and tests get three to five times faster. Checking against real data, waiting for runs, reviews and rollouts hardly do. Estimating by the amount of code gets it wrong. For the migration, a classic 12 to 17 person-days became a realistic 5 to 8.
The client got answers to all 14 questions, a recommendation with an order of steps and numbers — and the memory failure fixed before it had to show up in the estimate at all.