|
There are 2 sides to this, one of which is detailed in most comments below, and I see it from a lot of devs I work with but mainly the less experienced ones, and that is the eternal optimism issue. That's been covered a lot already, so no point in belaboring that. The OTHER side is that, at least given my experience in the financial software domain, managers don't WANT accurate estimates. They absolutely abhor them. And developers are punished for giving them. So they aren't given. An accurate estimate, such that one can be made, is usually around a 70%-80% confidence interval. It includes many specifically unforeseen, but generally known issues such as problems with the environment, lacking specifications and time required to get them, including "making $#@! up" fudge factors, technical hurdles, cogitation and exploration time, etc. But managers can't hear that. All they want to hear is something they can sell to their superiors, which is often the customer. An accurate estimate is almost always going to be larger than that, so they won't accept it. So, the development staff is forced to skimp on quality or features to make an artificial date. But that's ok! Why? Well, it's partially an organization's willingness to accept "there's never enough time to do it right, but there's always enough time to do it twice" (or more), but that's not even half of the issue. The larger part is that NO ONE WANTS IT RIGHT THE FIRST TIME. I've seen this time after time. It's a win/win to provide sub-par product. Why? It makes a manager look great to give low estimates (win), hold the developers to that, and deliver a product with less-than-promised quality, or scope, or both. That provides customers something to gripe about (which EVERY customer wants; it makes them appear "tough" or "thorough"; win), and it gives the managers something to "fix" and appear reactive to the customers' needs (win). Who's holding the bag for all this win? The devs, and support. There are inevitable promises of being able to go back and fix things, but that never happens; once something is in production, no matter how crappy, it has the almighty momentum. If it's "working", almost no matter how fragile it is, there's no appetite to change something that works so that it can work better. That provides no revenue, and does impart considerable risk (with limited or no QA, having moved on to the next thing) and/or cost (keeping your QA around to regress fixes). Although that mindset infuriates me, I don't honestly know that it's not the best way. It seems to have evolved, and companies that do it seem to do ok, so maybe it's the Darwinian process at work. |
The frustrating thing is that it means the uncertainty gets lost, and people just end of with a number, which managers may treat a fact, not an estimate. That's why I think it's a really good idea to give a range including both a low and a high estimate so you can let people know: "If everything goes right, it might take two hours", but warn them that: "It could take 4 days". Once people have that kind of information, they can make much more resilient plans.
That's why we always tell our CEO that it will take 2-4 hours or 4h-5d, and let me tell you, he appreciates knowing when we don't know, because a layer of false certainty is removed.