Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Poor developer estimates, a.k.a. guesstimation

alexefish.com

Post reply on HN
Print view View original

41–50 of 72 posts

Re: Poor developer estimates, a.k.a. guesstimation

#41

Post by dbg31415 »

A lot of the poor estimates come from not taking time to break out the features and subtasks of the project. Planning. Because clients never want to pay for planning.

We spend about 35% of the budget on planning and estimates. And they're usually fairly close, for projects where we've done similar things in the past.

When I worked at a smaller dev / consulting shop, we'd be lucky if we got 5-10% of the budget to spend on planning. Short sighted to say the least. Projects succeed or fail based on planning.

Re: Poor developer estimates, a.k.a. guesstimation

#42

Post by ams6110 »

pbreit wrote: post #34

I usually get pretty close by doubling the estimate and then cutting scope in half (or quadrupling estimate).

The classic rule of thumb is to double the estimate and bump up the unit of measure. So an estimate of 1 hour becomes 2 days; 1 day becomes 2 weeks, etc.

Re: Poor developer estimates, a.k.a. guesstimation

#43

Post by ExpiredLink »

MetaCosm wrote: post #3
onion2k wrote: post #2

This is actually a solved problem in some industries using a technique called "3 point analysis". I've no idea why it hasn't really caught on among developers; it's very useful. Essentially it goes like this: 1. Estimate the very best possible outcome. How long would something take if everything went to plan? 2. Estimate the very worst possible outcome. If everything that can go wrong does, how long will the task tak…

This is basically your solution: http://imgur.com/YNmKId9 PHB: Use the CRS database to size that market. Dilbert: That data is wrong. PHB: Then use the SIBS database. Dilbert: That data is also wrong. PHB: Can you average them? Dilbert: Sure. I can multiply them too. ----- I kid (sorta). It misses the core issue, why are developers estimates so terrible, 3 terrible estimates don't make a "good" one. The post hits on…

> Estimations are based on experience, yet developers are constantly building brand new types of products. If all you built was "blog engines" over and over again, you would get damned good at estimating them. The trick in software is as soon as something needs to be reused over and over again, it is abstracted, put in a library, built into a framework, so you can make your product different (read: build something entirely new) -- and EVERYONE sucks at estimating the cost of building things entirely new.

That's it. Most, actually all, literature on software estimation I've seem ignores this simple fact. It's feasible to estimate cost and time for building houses, even skyscrapers, if you do that all the time. But how long does it take to climb a never-climbed mountain?

Re: Poor developer estimates, a.k.a. guesstimation

#44

Post by DougWebb »

sateesh wrote: post #16
iancw wrote: post #7

I recently read Software Estimation (Steve McConnell, author of Code Complete). My main takeaway was to distrust developer intuition and instead build estimates from data. One example is to look at the duration of past projects of "similar size" (still requires some qualitative analysis). Another example is to count the number of distinct "features" or "components," and build an estimate from those. Both of these sti…

My main takeaway from the McConnel's book has been not to provide an estimate as a single point number (say something like it will be done in 5 weeks) but rather as a range (say something like 5-8 weeks), as providing a single point number would give the impression that it is the target date (while it is not). But unfortunately most of the times all I have got is blank stares when I give estimates as a range and a qu…

I ran into the same problem, and eventually the only workable solution was to use ranges within the software development group, but to only communicate the high end of the range to the project management group and executive team. Most of the time our projects came in "under budget" this way, which seems self-serving, and sometimes projects we thought we could complete on-time were shelved as being too-expensive, but whenever we tried to give those groups better information (eg: the range) they always went straight for the low-end and gave that out to marketing and other groups as a committed deadline date.

Re: Poor developer estimates, a.k.a. guesstimation

#45

Post by kabdib »

lobotryas wrote: post #5
MetaCosm wrote: post #3

Earlier quoted context omitted.

This is basically your solution: http://imgur.com/YNmKId9 PHB: Use the CRS database to size that market. Dilbert: That data is wrong. PHB: Then use the SIBS database. Dilbert: That data is also wrong. PHB: Can you average them? Dilbert: Sure. I can multiply them too. ----- I kid (sorta). It misses the core issue, why are developers estimates so terrible, 3 terrible estimates don't make a "good" one. The post hits on…

You are absolutely right. It's impossible to estimate how long it will take to complete something you have never done before in your life. Unless the new code being written is absolutely trivial, estimates are going to be guesses, at best. The only half-decent solution I found so far is iterative development. Take a feature and break it down i to big rocks. Further break down the big rocks into little chunks - each t…

Decomposing as far as you can is a good practice ... you'll still be way off, because you think you know all the problems that you're going to need to solve. So about halfway through the project your list is going to be longer and management is going to be freaking out.

The elephant in the room: Debugging. I don't know how many times I've been asked, "When are you going to find that bug?" Sometimes they are very easy. Sometimes they are very hard. For the really hard bugs, you need to be clever, scientific, determined, methodical and LUCKY. I don't know how to know when I'm going to run into some luck.

Re: Poor developer estimates, a.k.a. guesstimation

#47

Post by DanielBMarkham »

nradov wrote: post #38
DanielBMarkham wrote: post #29

I've ran across this topic on 3 occasions in the last week in various forms: online, with a team, and on a LinkedIn board. Wow, must be something in the air. So here's the short version: 1) Agile relationships with customers boil down to Time and Materials. You're there working sprint-by-sprint doing stuff. Each sprint the customer and the team agrees on what it can do. The team decides, but the customer can always f…

That technique tends to break down when you have multiple agile teams working through a long, complex dependency chain to deliver a single project. It's also problematic when your customer has to make fixed schedule commitments to their customers based on your work.

No, it doesn't.

Complex programs and dependencies are handled the way complex projects and dependencies are handled: visiblility, simplification, and just-in-time architectural support. Works at the team level, works at the program level.

Fixed calendar dates are also not an issue. Remember, the goal is to separate delivery from scheduling. There's no magic fix to make you automatically hit dates, but you can generate real numbers on what it takes to meet arbitrary calendar dates if that's your situation. You should know, for instance, that 2 more teams need to be spun up within the next week if your group is going to hit the date.

It's a myth that Agile team techniques don't scale out. This was true several years ago but a lot has changed since then. A better way of describing the situation is that there are multiple models for scaling out Agile teams and estimation, many of which have years of real-world traction. We don't have the same number of data points as we do with, say, how well stand-ups map to the average team, but we have data and we have demonstrable traction on the problem. All of the normal project and program management tools are available to Agile teams and programs.

For a discussion of how simple systems can scale out into complex projects, check out my 15-minute video. (Sorry for the additional plug, but it is relevant here) https://vimeo.com/57146799 Also for a review of the various Agile Program management systems out there, https://vimeo.com/64452664

Re: Poor developer estimates, a.k.a. guesstimation

#48

Post by phillmv »

ExpiredLink wrote: post #43
MetaCosm wrote: post #3

Earlier quoted context omitted.

This is basically your solution: http://imgur.com/YNmKId9 PHB: Use the CRS database to size that market. Dilbert: That data is wrong. PHB: Then use the SIBS database. Dilbert: That data is also wrong. PHB: Can you average them? Dilbert: Sure. I can multiply them too. ----- I kid (sorta). It misses the core issue, why are developers estimates so terrible, 3 terrible estimates don't make a "good" one. The post hits on…

> Estimations are based on experience, yet developers are constantly building brand new types of products. If all you built was "blog engines" over and over again, you would get damned good at estimating them. The trick in software is as soon as something needs to be reused over and over again, it is abstracted, put in a library, built into a framework, so you can make your product different (read: build something en…

And even then, large capital projects are routinely wildly off estimates. I think the delta in "how far off we were" just tends to be larger more frequently.

Re: Poor developer estimates, a.k.a. guesstimation

#49

Post by mbrock »

I think one thing we don't do enough of is prototyping. When we've built something before, we can usually estimate how long it's going to take this time if the differences are not huge and qualitative. But if we're building something new, or doing something that we've never done before, just thinking and guessing is a terrible way to estimate. We should learn to take the time to try things to see how difficult they are.

Re: Poor developer estimates, a.k.a. guesstimation

#50

Post by krisgee »

mbrock wrote: post #49

I think one thing we don't do enough of is prototyping. When we've built something before, we can usually estimate how long it's going to take this time if the differences are not huge and qualitative. But if we're building something new, or doing something that we've never done before, just thinking and guessing is a terrible way to estimate. We should learn to take the time to try things to see how difficult they a…

That's because in most cases if you build a prototype that works your boss/client doesn't want you to waste time making a better version, they just want the one that works now and doesn't require a hundred more (billable) hours from you.
Post reply on HN