Yes, Estimate Software Projects

I feel like no one does a convincing job at communicating why estimates matter (and how much value you get out of how precise of an estimate).

Fundamentally, an estimate (or any piece of information) is really only of value if you're going to do different things based on learning it. E.g., given an estimate, you might:

* Prioritize one project over another based on ROI.

* Know when to communicate that something might be available to users (though that's still not intrinsically valuable, you have to have some kind of marketing/sales-cycle based reason or something that it matters).

* Know when to begin supply-line stuff so that a factory is ready to build a thing as soon as possible (but no sooner, since then maybe you're holding up parts of the pipeline from doing other things? maybe?)

I feel like so often people try to underscore the importance of estimates but don't say anything remotely close to the above. A lot of times it's just "this is important/urgent". Ok, so? If it's urgent then that's even more reason to start actual work instead of spending time planning, if you can't point to a concrete thing you'll do differently having known the plan.

Even when people do talk about the actual reasons for wanting an estimate, it's always totally in the abstract. The precision of an estimate is always on a "delivery day" level, even if that level of precision is totally unnecessary for what this particular estimate was used for.

I think the real reason for this amount and kind of emphasis on estimating really has to do with:

1. Deadlines make people work harder/faster.

2. It gives people sticks with which to measure people/teams.

I think #2 is mostly straight-horseshit. #1 is maybe somewhat true, but I think it's not nearly as good as other ways of getting people motivated to work harder which have fewer negative externalities (e.g., more autonomy, instilling more of a sense of ownership).

An estimate is NOT A DATE, an estimate is a DURATION.

If you estimate 50hours and other things come up that eat into your time, you continually adjust the DATE, the duration shouldn't change. If you depend on an external sys and you estimate N hrs, but that system takes N+M hrs, then your duration date moves forward M hrs.

If there were unknowns, risks, as you uncover them, you move the date and if you communicated the unknowns and risks, then you can adjust the duration by adding the new info.

Ideally what you wish to do is eliminate all the unknowns and risk by NOT doing them. You're doing DEVELOPMENT not RESEARCH. Development is simply pulling in all your prior knowledge on how to solve problems and tacking similar or new problems.

Don't mix your R&D.

I've been doing dev work my whole life, and the only thing I can say about estimates is to underpromise and overdeliver.

What are the consequences of missing an estimate (especially one I did not create)? If it's "stay late until it's done" (with no OT because you're legally "exempt"), that sucks. If it's "your career is penalized, the same as if you were incompetent at the task itself", that sucks.

I'd rather go back to a low starting salary, and earn OT when my manager decides to keep me working late. The money isn't as important to me as aligning our goals.