Blog ·
Estimating changes to code that touches money
The code is usually a day. What surrounds it — understanding current behaviour, pinning it with tests, validating with the business, the deploy window — is the estimate.
Someone asks how long it takes to change how a payment is allocated. The honest answer isn’t about the code — and the first few times I got this wrong by a factor of three.
The code is usually a day. What surrounds it:
What surrounds the change
Understanding the current behaviour. Not what the system should do — what it does, including the cases nobody documented. This is where the surprises live, and it’s unbudgetable in advance — which is itself information.
Characterization tests. Pinning today’s behaviour before touching anything, against a real database. Often longer than the change itself.
Validating with the business. If the change alters a number anyone has seen, someone has to confirm the new number is right. That’s a conversation, and conversations happen on someone else’s calendar.
The deploy window. Money code doesn’t ship at 5pm on a Friday, and it usually doesn’t ship during business hours either. Between “the technical work is done” and “the change is live” sits a scheduling problem, not a code problem.
The watching period afterwards. The change isn’t “done” when it deploys: it’s done when enough real operation has run over it.
The estimate has a shape, not a number
The change is small, the verification is the work, and the calendar is the constraint.
Two things I now do at the start. I say out loud which part I’m uncertain about — almost always, the current behaviour — instead of padding a single number that hides it. And I split every estimate in two: “when it can be done” and “when it can be deployed”, because for a system in production those are different questions with different answers.
Being wrong about how long code takes is normal. Being wrong about what surrounds it is what makes you unreliable.