"How long will this take?"
It is Monday, just before lunch. The engineer stares at the Jira ticket. It reads: Add CSV export to Admin Panel.
Their brain immediately lights up. They mentally trace the code path: SELECT * FROM users, loop through records, format string, download. It’s a trivial algorithmic problem. They’ve done it a dozen times.
"I'll knock it out this afternoon," the engineer says. "Maybe tomorrow morning if CI is slow."
It is now Thursday. The engineer is sweating. The CSV export is consuming 4GB of RAM and repeatedly OOM-killing the production container. The legacy data contains unescaped commas and non-UTF-8 characters that broke the parser. And the Product Manager is standing at their desk asking if it’s live yet.
We have all been this engineer - convinced on Monday, apologizing on Thursday.
The estimate was 4 hours. The reality was 24 working hours, spread across four calendar days.. This isn't a story about incompetence - this engineer is likely the smartest person in the room. They are simply a victim of the Planning Fallacy.
Your Brain is a Liar
The problem isn't technical, it's biological. When you are asked to estimate a task, your brain treats it as a logic puzzle. You simulate the happy path. You visualize yourself writing the code, the tests passing and the green checkmark appearing. This visualization releases dopamine. It feels good to solve the puzzle.
What your brain refuses to simulate is the friction.
It is biologically difficult to visualize waiting. You don't picture yourself sitting in a Slack channel for 3 hours waiting for a code review. You don't picture yourself reading a confusing error message on StackOverflow. You don't picture the context switching.
We estimate the drive based on an empty highway, conveniently forgetting that every previous time we drove this road, there was a traffic jam.
The 90/90 Rule (Or: The "Done" Delusion)
If you ask a developer when a task is "done", they mean "Code Complete." If you ask a Product Manager when a task is "done", they mean "Production Ready."
The chasm between these two definitions is where estimates go to die. This is the 90/90 Rule: The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the time.
Think about the hidden tax required to take a feature from "Works on My Machine" to "Works in Prod":
- Integration Tests: Not just unit tests, but the flaky E2E tests that fail because the staging DB was cold.
- Observability: Adding logs so you don't wake up at 3 AM.
- The Review Queue: This is the silent killer. You finish code at 2 PM. You get a review at 10 AM the next day. You fix comments. You wait again. A "4-hour task" spans 3 calendar days purely due to queuing theory.
If your estimate doesn't include the time it takes to fight Terraform or wait for a coworker to finish lunch, it’s not an estimate. It’s a wish.
The Hero Complex & Imposter Syndrome
There is a deeper, darker reason we underestimate: Fear.
In engineering culture, speed is often conflated with competence. When a Manager asks for an estimate, there is immense social pressure to give a "good" number.
If you say, "This simple button will take me 3 days because I need to account for testing, docs and potential legacy debt", a voice in your head whispers: They will think I'm slow. They will think I'm incompetent. They could hire a '10x engineer' who would do this in 4 hours.
So you say "4 hours" to signal your value to the tribe.
But it backfires. The moment you hit a snag (and you always hit a snag), you shift psychologically from "Creator" to "Debtor." You rush. You skip tests. You hack together a solution. You introduce bugs. The aggressive estimate creates the very chaos that ensures the next estimate will also be missed.
The "Invisible" Work (Or: Why Jenkins Hates You)
We also have to talk about the tools.
In 2015, you might have just FTP'd a file. In 2026, a "simple" change involves updating a Docker container, pushing to a registry, updating a Helm chart and waiting for ArgoCD to sync.
We rarely factor this "infrastructure tax" into our estimates. We assume the tooling will work perfectly.
But how often does a Sprint derail because "Docker is acting up" or "npm install failed due to a sub-dependency"? You finished the feature logic in 2 hours. But then you spent 6 hours fixing a CI pipeline that died for no reason. This isn't "bad luck". This is the baseline reality of modern development.
How to Stop Lying
So, are we doomed? No. But we have to fundamentally change how we talk about time.
1. The "Yesterday" Rule
Stop asking "How long will this take?" Start asking "How long did something like this take last time?"
Ignore the specifics. Look at the class of the ticket.
- Ticket: "Build a new Settings page."
- History: The last 3 Settings pages took 5 days, 4 days, and 6 days.
- Estimate: 5 days. It doesn't matter if you think you can do it in 2. The data says 5. Trust the data.
2. Estimate for the Junior, Not Yourself
When Seniors estimate, they suffer from the Curse of Knowledge. They know where the helper functions are. They know the database schema by heart. A Junior Dev has none of this. They will spend 6 hours just finding the right file. Rule of thumb: Never estimate how long it takes you. Estimate how long it takes the person on the team with the least context.
3. The 4-Hour Day
If you work an 8-hour day, you probably only get 4 hours of "Deep Work". The rest is meetings, Slack, email and lunch. If a task takes 20 hours of effort, that is not 2.5 days. At 4 hours/day of effective velocity, that is 5 days.
The Trust Battery
Why does this matter?
Because bad estimates destroy trust. Every time we promise "Tuesday" and deliver "Friday", we drain the Trust Battery between Engineering and the Business. Marketing launches campaigns that have to be pulled. Sales promises features that aren't there. Leadership starts to micromanage because they feel they can't rely on us.
The most "Senior" thing you can do is not to code faster, but to predict more accurately.
It is uncomfortable to look a manager in the eye and say, "This simple button will take a week". But it is far better to have that uncomfortable conversation on Monday than to have the "Why isn't it done?" conversation on Friday.
The next time you feel the urge to say "I'll just...", stop. Remember the CSV export. And double the estimate.
Frequently Asked Questions
What is the planning fallacy in software development?
The planning fallacy is the cognitive bias where people underestimate the time, cost, and risk of a task while overestimating its benefits - even when they have direct experience of similar tasks taking longer. In software, it manifests as developers estimating the "happy path" (clean code, passing tests, no surprises) and forgetting the friction: code review queues, flaky CI, unescaped legacy data, and the gap between "works on my machine" and "works in production."
Why do software estimates consistently run over?
Software estimates run over because the brain simulates the happy path when estimating. Developers visualise writing the code and the green checkmark - not the three hours waiting for a code review, the CI pipeline failure, or the legacy data edge case that breaks the parser. The estimate is for an idealised parallel version of the task with no queuing, no surprises, and no context switching. Real work has all three.
What is the 90/90 rule in software development?
The 90/90 rule states: the first 90% of the code accounts for the first 90% of the development time, and the remaining 10% of the code accounts for the other 90% of the time. It captures the hidden cost of taking a feature from "code complete" to "production ready" - integration tests, observability, code review cycles, staging fixes, and deployment steps that were not in the original estimate.
How should engineering teams give more accurate software estimates?
Three techniques help: use historical data ("how long did the last three similar tasks actually take?") rather than the current task's apparent simplicity; estimate for the team member with the least context, not the person writing the estimate; and use a 4-hour effective workday (accounting for meetings, Slack, and context-switching) when converting effort hours to calendar days. Combining all three typically produces estimates that are within 20% of reality rather than 3-5× off.
What is the "Trust Battery" in software engineering?
The Trust Battery is the accumulated credibility between an engineering team and the rest of the business, charged by accurate commitments and drained by missed deadlines. Every time a team promises "Tuesday" and delivers "Friday," stakeholders lose confidence and respond with tighter oversight, more status meetings, and scepticism of future estimates. The most senior thing an engineer can do is not code faster - it is predict more accurately and preserve that trust.