An engineer's estimate is usually right about the coding and wrong about everything around it. So when one lands on my desk, I don't check the hours per feature. I check what the estimate quietly assumes: what is already working, what we are waiting on, who reviews the work, and how much of it is testing. That review takes me thirty minutes and it has saved more client relationships than any status report.
What am I actually looking for?
Four things, in this order, and none of them is the hours per feature. What the estimate assumes already exists. What sits outside our control. Where the vague ticket is hiding. And who reviews the work once it is written. Half an hour, every time, before a number leaves the building.
- What does this assume already exists? An estimate for "add invoice PDF export" assumes the invoice data model is clean and complete. If it isn't, the export is a data-cleanup project wearing a small feature's clothes.
- What sits outside our control? A payment sandbox, a client-side approval, a vendor's onboarding queue. Engineers estimate the work they will do; the calendar time is set by the work they won't.
- Where is the "we'll figure it out" ticket? Every estimate has one. It is usually the integration or the migration, and it carries a suspiciously round number. That ticket gets broken down before anything ships to the client.
- Who reviews it, and when? Review time is almost never in the estimate. Neither is the second round of fixes after review. Both are real hours.
| Line item | In the engineer's estimate | In the number I send out |
|---|---|---|
| Coding | Present, and usually about right | Same hours, left alone |
| Code review and rework | Rarely there at all | Budgeted as real, named hours |
| QA | Sometimes, and first to be cut | Roughly 10% of build hours, held |
| Waiting on the client | Never | Named risks with owners and dates |
Has AI made estimates better or worse?
Worse, in a specific way. Coding assistants made engineers faster at the part they were already good at estimating, so the coding line shrank. Review and integration did not get faster, and there is now more code to review. The total moves far less than the coding line suggests.
I have watched a feature's build hours drop by half while the calendar time barely moved, and the missing time was all in checking the output. That is why the testing line in my estimates has stopped shrinking. Our template pegs QA at roughly ten percent of build hours, and I no longer let anyone cut it, however confident the demo looks. The reasoning in the QA layer that has to grow when AI writes four times the code matches what I see on every project now: more output, same number of eyes, so the eyes need budget.
A number or a range?
A range, with one sentence about what pushes it to the top. "Six to nine weeks; nine if the legacy export turns out to be undocumented." Clients handle ranges better than most engineers expect, as long as the range comes with a reason and a date by which it will narrow.
What clients cannot handle is a single number that turns out to be the bottom of a range nobody mentioned. That is where the word "overrun" comes from.
What do I do with an optimistic engineer?
I don't double it. Silently padding an estimate was my mistake for years, and it had a cost I didn't see for a long time: the team learned that my number was never their number, so they stopped owning the date. It became "Sonal's estimate".
Now I ask them to walk me through the first five days, task by task. Optimism collapses under a day-by-day walk. Around day three there is a pause, and then "oh, we'd need the staging environment by then". The padding still ends up in the plan, but as named risks with owners, visible to the client, and it is the engineer's plan.
At Shanti Infosoft no estimate reaches a client without that walk-through, and the same habit sits behind the software consulting work we do for teams who want a second opinion on somebody else's number. I would rather delay a proposal by a day than send a clean-looking figure I don't believe.
When you last missed a date, was the coding late, or was it everything wrapped around the coding?
Sonal Jain heads delivery at Shanti Infosoft, a CMMI Level 5 company, and reviews every estimate before it reaches a client.
