I'm pretty sure if you've broken down a larger task to 1-hour pieces, you've already done a large part of the software engineering work. So you've implicitly consumed a considerable amount of (not accounted-for) project time.
My impression has always been that the true cost of a dev task is only revealed when solving it. That's why they're hard to estimate. If they were easy to estimate, they would be trivial to implement and therefore could be largely automated. And for the lack of work, we'd aim for the next larger goal (which is again hard to achieve and estimate).
> If they were easy to estimate, they would be trivial to implement and therefore could be largely automated.
This seems to be a concept so hard to grasp for non technical managers.
By definition tasks aren’t that similar to other tasks, otherwise we would be a super crappy software shop that can’t provide semi-generic solutions.
Dev team’s mission is to solve unique problems to the stack. Discovery is a major time consuming task by definition, and can’t be properly estimated, as it’s an information problem.
My impression has always been that the true cost of a dev task is only revealed when solving it. That's why they're hard to estimate. If they were easy to estimate, they would be trivial to implement and therefore could be largely automated. And for the lack of work, we'd aim for the next larger goal (which is again hard to achieve and estimate).