Our experiences obviously differ. Usually it goes like this - the developer gives his best estimate (which is, by the way, hard by itself - a lot of things has to be taken into account), and that estimate is considered too high. So the developer is ordered - in one form or another - to, effectively, "do it faster". Often it's by cutting corners in places deemed least important - but then it also reduces probability of the correct estimate overall. One more thing - specifications are quite rarely are good enough - there are other reasons why that's the case - and the final result causes management to wonder, why it doesn't include this, of why that works this clumsy way. So nobody's happy - and developer pays the price. It may look as the developer isn't good at writing software... because "writing software" is a sort of encompassing figure.

well maybe it doesnt happen at a "developer" level, if that's what the management hierarchy calls it. But it definitely does happen on an engineering manager level and is actually fairly common in the VP Engineering role.

I'd agree with this. I've seen Project Managers let go because projects overrun, but never a developer because of bad estimation. And this is based on about 20 years experience in Investment Banking IT, not the most cuddly of environments.

You must have good customers then that value quality software over meeting deadlines. Not government I take it?!