24th September 2014
No, it is because estimating software tasks is difficult, the penalty for underestimating is that people think you are dishonest/flakey, and there isn't anywhere to get an education in how to do it well. The default advice given to junior engineers is therefore: "take your intuition and triple it." I hate that this is the state of the industry. My interactions around estimation over the past 5 years since uni have literally made me feel nauseated and near fainting on multiple occasions. I would love for Joel or Klamezius or Uncle Bob or someone else to fix it and produce a good course on how to create estimates.
Probably the best your going get is the book "Software Estimation: Demystifying the Black Art "
Even applying those techniques you get it wrong.
Most experienced software companies have adopted agile, and accept reductions in scope to meet deadlines as something that happens.
Of course, all this leads to bad blood between techies and business side: how long will it take? -> probably about 3 weeks, but this requires using a library we haven't used before, so in the worst case even 2 months -> what? so long? get it done in 4 days, this is required the next week -> no, that's not really possible -> make it happen -> it happens and it either sucks when it's delivered at all, so the deadline gets extended anyway to iron out all the bugs or it causes lots of problems in the future.
"OK you have implemented it as requested, but finally the customer does not like it, it needs to be slightly different. Can you do it quickly?"
Sometimes it is easy to adapt, sometimes next to impossible.