This is an excellent article. It's a great synopsis of what's really behind those estimates, whether in naked form or couched in that "story points" bullshit of the "Agile" cult. I fucking hate all of it.

Here's my take. Programmers don't underestimate because they're afraid of getting fired or yelled at. In this market, a good developer is unlikely to be fired for honestly estimating. Yelled at, yes. Fired in worse economic circumstances (e.g. 2003)? Possibly. Fired now? Doubtful. Rather, it's about a desire not to be jerked around. Implicit in the demand for an estimate is the threat to jerk the employee around-- either imposing stupid new micromanagement ("Agile") or changing project priorities. No one wants to work for the boss who jerks her around and never lets her finish anything, because soon enough she gets to 3 years and while she's fixed bugs and added a few features, she doesn't have the coherent project that would make the case for promotion or transfer to her target group... because her boss kept jerking her away from projects whenever his hindbrain misfired, he interpreted it as the "this is taking too damn long" impulse, he got impatient, and pulled support. It's a fight-or-flight reaction in the boss when that happens, and managers tend to favor flight because fighters tend to get themselves fired. If you work for a hair trigger "flighter", you can very easily get to 3 or even 10 years without ever actually finishing a project. And flighters love estimates.

A good middle manager isn't one who exacts and reports reliable estimates. A good manager goes out, wines and dines the executives, and gets sufficient credibility for his people that no one ever has to give an estimate.

Anyway, programmers give misleadingly optimistic estimates-- not dishonest, just aggressively optimistic-- because they want to be left alone so they can actually produce something and move along to a better project. This is what "Agile" doesn't get. The thing that motivates us is delivering a major project that gives us enough credibility that we never have to make estimates again; not delivering small cantrips that anyone could do, but in record time. I think that "Agile" provides some structure for junior programmers, but it doesn't provide an exit. Under the Agile Ideology, even the senior programmers in R&D and architectural rules have to structure their work in terms of these dumbass "iterations". Implicit to Agile is the absence of personal progress for an engineer: no matter what you do, you'll always be working on feature-level "user stories" instead of real projects where you call the shots, and you'll always be subordinate to the business.

I've been doing this for almost 10 years and I'm good at it, so what being asked for an estimate communicates to me is that whatever I'm doing isn't really important. I will do what is necessary to meet a real, hard deadline (they're rare, but they exist) such as a bid deadline for a government agency (where people can go to jail for corruption if they grant an exception to someone who's a day late) but the silly deadlines that business usually creates are just resource limits, and (sorry but) I'm too good to work on something so unimportant that I'm not even trusted with a month or few of my own time on it. If you won't accept delivery on my time, then it's not important enough to be doing in the first place, because I will work very hard to make sure it's done reasonably quickly and well, and if you don't trust me on that much, then you should just fire me.

In other words, the difference between "4 weeks" and "2 weeks" is going to mean that I either don't get to do it or have to relegate it to extra hours, then (unless there is a hard deadline, and not some silly target like "Q3 KPIs") it's just not fucking important enough for someone at my level of skill to be doing. So give it to some junior who'll view absolutely anything as a learning experience, and leave me out of it.