The Estimation Problem in Software Development
I am yet to behold the day when I complete the work within the estimated time.
Parkinson’s law states, “work expands so as to fill the time available for its completion”.
But I’d say, work in software development expands so as to fill double the time available for its completion.
A quick Google search shows I’m not alone with this problem. There is an entire book on this topic by Steve McConnell: Software Estimation: Demystifying the Black Art
What to Say When Asked for an Estimate
You say “I’ll get back to you.”
You almost always get better results if you slow the process down and spend some time going through the steps we describe in this section. Estimates given at the coffee machine will (like the coffee) come back to haunt you. — from the book The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas.
I suppose, when we estimate the work to be done, besides the fact that we are only guessing based on the limited knowledge we possess on the work, we calculate the ideal time needed for the work.
But we are not in an ideal world.
There are distractions in the workplace.
There are dependencies in the work we do.
There might be some unknown bugs that slow us down.
In the book Rework, DHH and Jason Fried says “Planning is Guessing” and “Your estimations suck”. They advise not to do planning and estimation for the next months. Instead, break the work down into small chunks that can be measured in days.
They say this not because we can estimate correctly in days, but because we will be wrong only small if we measure in days.
I am yet to behold the day when I complete the work within the estimated time.
