Deadly sins of software estimation

I work as a programmer, and sometimes I am surprised that software companies even succeed to exist. Most managers seem like devoted anti-rationalists. Sometimes it is comfortable to believe that they see some aspects that I don't, and therefore their decisions make some sense from the business point of view (maybe the customer really wants something that doesn't work and is produced late -- if they are willing to pay for that, who am I to argue?). But sometimes I talk with other managers who confirm that most stupid decisions were in fact stupid. And even if there is a reason, the reason is often "it helped the manager get some political advantage within the company, but it harmed the company as a whole".

Estimating how long "it" will take to build before anyone knows what "it" is

Well, of course you do it this way. First, you estimate the necessary man-days, because this is how you estimate the total budget. Then you negotiate how much the customer is willing to pay, and then you decide whether you take the project (the answer is always "yes", btw). Only then you start paying the technical people to figure out the details, such as: what exactly did you actually agree to build.

Assuming that the most reliable estimates come from the people with the most powerful vocal chords

Okay, this one is obviously wrong. The most reliable estimates are the shortest ones. Because people who make the shortest estimates are obviously the most competent people; therefore you should trust them most.

Creating an estimate for a new project by comparing it to a past project... which overran its estimates... and ultimately realizing that you based the new project's plans on the past project’s estimated results instead of its actual results

This makes perfect sense in a company setting. When we did the previous project, we had not enough experience, and we [insert random excuse]. This is why we overran the estimates. But now we have already learned everything necessary, so this time we will be able to do it much faster.

Overestimating Savings from New Tools or Methods

Are you telling me that if we use Oracle + Java + XHTML, the project isn't going to write itself? Okay, then what other technology should I use to achieve the same magical outcome?

Must pay learning curve price during first use

Sure, the 4-hour training is included in the budget. It can't be that complicated, right? My neighbor's nephew created his own web page in PHP after reading an online tutorial, so web applications can't be much more difficult. In worst case, we can do without some of the most advanced features.

I especially liked:

Sin #4 Assuming Underestimation has No Impact on Project Results

Which is another example of "Rushing Slows You Down", which I apply to a lot of skill execution tasks.