I always have a hard time estimating time.
I first read about the concept of “flow” in FatLemon’s blog and agrees with how developers work. Non-developers should understand how developers work in order to understand why time is estimated as such.
Paraphrasing from FatLemon:
When a software developer thinks up an estimated time to complete a development task - they’re thinking solely in flow time.
Paraphrasing from Peopleware on what is flow time:
During single-minded work time, people are ideally in a state that psychologists call flow. Flow is a condition of deep, nearly meditative involvement. In this state, there is a gentle sense of euphoria, and one is largely unaware of the passage of time: I began to work. I looked up, and three hours had passed. There is no consciousness of effort; the work just seems to, well, flow. You’ve been in this state often, so we don’t have to describe it to you.
Not all work roles require that you attain a state of flow in order to be productive, but for anyone involved in engineering, design, development, writing, or like tasks, flow is a must. These are high-momentum tasks. It’s only when you’re in flow that the work goes well.
In other words, the model that software developers work in is unlike a conventional model. The amount of work accomplished by a developer is NOT proportional to the number of hours put in. What matters is the amount of time that a developer is working at full potential.
An hour in flow really accomplishes something, but ten six-minute work periods sandwiched between eleven interruptions won’t accomplish anything.
So when a developer estimates that a task require an hour, he means an uninterrupted hour.