31–40 of 134 posts
> It's not just developers that are bad with estimates either. Everyone at some point is just winging it because it's something they've never done before and won't be able to successfully make a judgement until they have.
When my manager asks, "How long will this take," about half the time my honest answer is, "I don't know."
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.
I prefer to take my advice from someone who has demonstrated the ability to repeatedly run projects and estimate them in advance to surprisingly high accuracy. I therefore recommend Software Estimation by Steve McConnell, available at http://www.amazon.com/Software-Estimation-Demystifying-Pract... .
Also if anyone wants some more good books to read we have a list of some of our favorite project management books at http://www.liquidplanner.com/recommended-reading.
The author makes the point nicely at the front: "because the nature of the work is creating." I'm not a developer but I can confidently say that it's not just developers - NO ONE can estimate time when it comes to creative work. I use the term creative loosely, it could be anything from developing a business strategy, to crafting a story, to art directing an original visual, to writing code for a novel problem. The p…
In the post industrial world time isn't the problem but rather project definition and scoping.
In the industrial world the problem was already solved (machine was built, market often established and output depended on a few factors that could be adjusted. Need more output add more of X)
In the post industrial world every project is about problem solving and scoping.
To put it into comparison.
If we apply post-industrial thinking to an industrial world. It means that each time a product needed to be done if not the factory, then the machines would have to be developed.
It will take many many years before time estimation will die, but it will happen.
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.…
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.…
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.
[1] http://www.mountaingoatsoftware.com/books/1-agile-estimating...
That's why we were using complexity estimates in points (say 1 to 5) instead of actual time estimates in my last startup. Once you have some worklog, it's easy to calculate how many points the team can get done in a week (or whatever your estimation cycle is). This little abstraction made estimates much more reliable. I guess some "agile" methodologies propose a similiar approach, but we didn't really follow any spec…