A bad estimate causes a delay to the project schedule (in the sense the schedule is delayed, not in the sense the software takes longer to write) . It's not th

A bad estimate causes a delay to the project schedule (in the sense the schedule is delayed, not in the sense the software takes longer to write) . It's not the same kind of delay, but to many stakeholders it's perceived as the same kind of delay. > Estimates are not called "promises" for a reason, and any attempt at treating them that way will result in failure. So management 95% of the time treats estimates as commitments. What they are going to do with the numbers you give them is promise upper management or clients "feature x will be done by y". As engineers we have two options, scream until we're blue in the face "that was an estimate not a commitment" or just give them a commitment and call it an estimate. You're right software estimation is hard, but the really bad estimates I've seen (> 100% over) were due to a combination of dysfunctional organizations, lack of estimating skill, and an organization that didn't put effort into making sure it's estimates were right.