going off of the post, I find that getting estimates wrong is also because a. not enough time is given to come up with good estimates b. Programmers usually d

going off of the post, I find that getting estimates wrong is also because a. not enough time is given to come up with good estimates b. Programmers usually don't enjoy the process of estimating and so don't do it properly c. Previous estimates are usually not shared amongst programmers To elaborate. a. There is usually pressure from managers or clients to come up with quick 'ballpark' estimates but only treat them as such when they don't fit their plans. So say they want something done in under 6 days. If you estimate a day ... there might be no questions asked, until you start blowing deadlines. But if you estimate 10 days, then a lot of people will quibble with you, trying to pressure you to give rationale or otherwise reduce the estimate. As the poster shows, properly estimating something is actually a pretty involved process that means constructing the thing you're trying to build on paper (or in your head). Clients/bosses don't want to pay for that time, so devs are implicitly pressured to underestimate things, to avoid long discussions about unfavorable estimates. b. Teeing off of a. clearly building the damned thing is way more fun than constructing it in your brain, estimating it, then going back and forth with clients on each line item as described above. There isn't a particular process, and sometimes you might actually spend almost half of the time of the estimate actually figuring out how to do it. Devs simply don't like estimating things, so they make (bad) guesses that seem safe but eventually turn out way wrong. On a project I had once, I hated the work so much that I simply took a wild guess at how long it would take to do one particularly hairy bit and doubled it. Seemed totally safe at the time ... figured I'd be under by a lot. Turned out being even double that estimate ... the culprit ... Internet explorer. c. If you go to a mechanic shop to get an estimate for work on your car, you might find that the mechanics go into a computer, plug in some details about your car and the problem ... and the computer spits out a number. This is because lots of things with cars are pretty routine ... Software isn't like that ... stuff that's routine is usually pulled out into plugins and frameworks that just work ... so we're constantly tackling problems that seem new, throw in the capabilities and weaknesses of particular frameworks, plugins or programming languages and you can see how these sorts of things can get away from you very quickly. Programmers don't share their estimates with each other (hint hint), so the only really reliable source of good estimates tends to be personal experience, which is another reason why you should code ... a lot. The only really good process I've found is to completely wireframe what needs to be done, (either that or build a clickable prototype that works exactly the way they want it to work). Then provide an estimate for that. But that doesn't always work for smaller things like bug fixes or smaller features.