Developers, in my experience, are quite often asked to leave the company after such estimates.
I've seen developers let go because they weren't very good at writing software. I've seen developers let go because they were painfully anti-social to the point that they were negatively impacting the rest of the organization. I have never ever seen a developer let go because their estimates were crappy.
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.
That's not bad estimating though. That's psychopathic management. The developer gives an estimate which is "too long" for the manager, who responds by essentially ignoring the estimate and laying down arbitrary deadlines. Surprise, surprise the arbitrary deadlines are missed, and the psychopathic manager blames the developer.
The developer's ability to estimate accurately is not an significant factor in this scenario.
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.
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.
Right, I've seen that and I'm okay with it. At the individual developer stratum, you expect the level of naivete that was in the original article we're discussing.
At the VP level, you're expected to understand what the Developers and Development Managers don't know about the SDLC. You're expected to bridge the gap in their lack of understanding by instituting processes and controls while mentoring them to become better at what they do so that the organization can succeed.
I've seen developers let go because they weren't very good at writing software. I've seen developers let go because they were painfully anti-social to the point that they were negatively impacting the rest of the organization. I have never ever seen a developer let go because their estimates were crappy.