Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Overconfidence: Why You Suck At Making Development Time Estimates

Soulskill posted 1 year,12 hours | from the i-blame-the-schools dept.

Programming 297

Dan Milstein from Hut 8 Labs has written a lengthy post about why software developers often struggle to estimate the time required to implement their projects. Drawing on lessons from a book called Thinking Fast and Slow by Dan Kahneman, he explains how overconfidence frequently leads to underestimations of a project's complexity. Unfortunately, the nature of overconfidence makes it tough to compensate. Quoting: "Specifically, in many, many situations, the following three things hold true: 1- 'Expert' predictions about some future event are so completely unreliable as to be basically meaningless 2- Nonetheless, the experts in question are extremely confident about the accuracy of their predictions. 3- And, best of all: absolutely nothing seems to be able to diminish the confidence that experts feel. The last one is truly remarkable: even if experts try to honestly face evidence of their own past failures, even if they deeply understand this flaw in human cognition they will still feel a deep sense of confidence in the accuracy of their predictions. As Kahneman explains it, after telling an amazing story about his own failing on this front: 'The confidence you will experience in your future judgments will not be diminished by what you just read, even if you believe every word.'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


I am confident thqt this is the (-1)

Anonymous Coward | 1 year,12 hours | (#43529599)

first post

Re:I am confident thqt this is the (0)

Anonymous Coward | 1 year,12 hours | (#43529645)

I'm not an expert in these manners, but I think you're supposed to post an APK troll as the first post.

Re:I am confident thqt this is the (4, Funny)

Anonymous Coward | 1 year,11 hours | (#43529805)

I think they finally blocked the APK posts with a HOSTS file.

Re:I am confident thqt this is the (1)

Anonymous Coward | 1 year,11 hours | (#43530033)

APK was arrested last night for disturbing the public and public indecency. Basically, his meds weren't adjusted (yeah, you probably noticed) and police officers don't like it when you masturbate in public, run around naked, and hurl your shit at them.

I sucked because I was pressureed to being sucky (4, Insightful)

Anonymous Coward | 1 year,12 hours | (#43529631)

'nuff said.

We've all been under pressure to give our "best" estimates and then some.

Give a realistic estimate? Off to India!

Sounds like ... (0, Troll)

jamesl (106902) | 1 year,12 hours | (#43529637)

... predictions of catastrophic anthropogenic global warming.

1- 'Expert' predictions about some future event are so completely unreliable as to be basically meaningless.
2- Nonetheless, the experts in question are extremely confident about the accuracy of their predictions.
3- And, best of all: absolutely nothing seems to be able to diminish the confidence that experts feel.

Re:Sounds like ... (0)

Anonymous Coward | 1 year,11 hours | (#43529871)

If by " completely unreliable" you mean "accurately predicting experimental and observational data" then yes.

Mod down, because reality goes the other way. (1)

Anonymous Coward | 1 year,10 hours | (#43530399)

Ice melting in the Arctic? Going FASTER than predicted.
Drought counts and length? Getting worse FASTER than predicted.
CO2 increases? Getting worse FASTER than thought.

The reason why #3 is true is because the moderated and generally-agreed results (which are necessarily going to be conservative) have been over-conservative when measured up to reality.

Hansen's 1988 paper so often touted by deniers as "heinously wrong, tenfold error!" was actually pretty damn close in its 30 year prediction. A sensitivity of 3.2C per doubling would have been spot on, but Hansen's model predicted a 3.4C per doubling figure.

Too many factors. (0)

Threni (635302) | 1 year,12 hours | (#43529639)

There's problems with the dev machines and environments, changing specs (including specs which are just stupid and need changing by someone with some sort of clue, rather than an overpaid 'analyst' who's just cutting and pasting stuff they don't understand from other people's documents), unforeseen problems during development, resourcing difficulties - all for a fuckwit of a manager with no technical experience who just wants a number they can enter into an email.

Pi (0)

Anonymous Coward | 1 year,12 hours | (#43529643)

I found that if I multiply by Pi my estimated time I'm usually right on target !

Re:Pi (4, Informative)

DaveAtFraud (460127) | 1 year,11 hours | (#43530063)

I usually take whatever estimate I'm given and change it to the next largest unit and double it. Thus, an estimate of two hours become four days. This is still usually less than the actual time required. And don't even get me started on projecting when some task will be completed as opposed to how much effort will be required. The above alogorithm does a reasonable job at estimating effort actually requied but determining the calendar completion date is a whole different animal.


Re:Pi (0)

Anonymous Coward | 1 year,11 hours | (#43530245)

I do roughly the same thing, works out well for me as well, it took me awhile to actually trust that it would work.

Re:Pi (0)

Anonymous Coward | 1 year,10 hours | (#43530349)

Also very similar. I have had very little trouble in estimating development time.
Upper management on the other hand, has a very poor record of underestimating time, and making delivery promises based on that value.
And guess who catches hell when that doesnt happen......

I guess I'm not an expert then.... (4, Insightful)

mark-t (151149) | 1 year,12 hours | (#43529655)

Points 2 and 3 don't seem to apply to me. I know I suck at doing development estimates. When asked for one, I've never been particularly confident about any estimate I give having a good chance of being accurate. I want to estimate conservatively, but project schedules don't allow for that.

Re:I guess I'm not an expert then.... (-1)

Anonymous Coward | 1 year,11 hours | (#43529823)

An evening with malt liquor and plenty of gunfire ended with feces and a trip to the Indian River County Jail for an Orlando man, according to a recently released arrest affidavit.

An Indian River County sheriff's deputy about 9:20 p.m. April 9 went to the Gifford Docks in Vero Beach after a report of shots fired.

He found Michael Johnston, 44, who said he'd had eight drinks, including two cans of Colt 45, which he said was "too many apparently!" Another man was with him.

Johnston, of Orlando, verified they'd been firing weapons, and said the guns were his and in his vehicle's trunk. A .40 caliber Glock pistol and a .45 caliber black powder handgun turned up in the trunk.

Johnston said both men fired weapons on the dock, and that he'd been "drinking and shooting." About 20 shots were fired, he said.

The deputy saw bullet holes and other gunfire damage on the dock area. Johnston said the damage came from him shooting at a glass bottle, saying, "the dock (feces) was my (feces)!"

Johnston was swaying as the deputy spoke to him and defecated in his trousers, the affidavit states.

The context of the affidavit narrative suggests Johnston's reference to "the dock (feces)" being his "(feces)" referred to the gunfire damage, as opposed to the apparent feces in his pants.

Drinking and defecating is legal. Drinking and shooting, maybe not so much.

Johnson was arrested on misdemeanor charges including using a firearm while under the influence of alcoholic beverages and criminal mischief.

The affidavit didn't state whether Johnston hit the glass bottle.

Re:I guess I'm not an expert then.... (4, Interesting)

Dixie_Flatline (5077) | 1 year,11 hours | (#43529975)

I guess part of being an 'expert' is being dumb enough to buy your own crap. That's why they always seem so sure of everything. Meanwhile, folks like you and me hedge our bets, and people attribute that to not knowing enough, rather than knowing all too well what the real deal is.

I suspect that prior to being an 'expert', that person makes one wild guess that they nail bang on. After that, they just point back to the ONE TIME they were right, and that carries them for the next few years.

Re:I guess I'm not an expert then.... (4, Insightful)

nine-times (778537) | 1 year,11 hours | (#43530279)

I wish people would understand that project schedules should *only* be considered guesses and estimates. Take the time you think it will take, and then take a step back and ask yourself, "No really, how long will it take?" When you get a number, take another step back and ask yourself, "No, *really*, when a bunch of things go wrong and it takes longer than I expect, how long will it take?" And then treat that time frame as a best-case scenario.

Part of the problem is that many projects can not be set to a specific schedule. The real answer is usually "it depends". How long will it take to build a new website? Well it depends on what unexpected hurdles we run into. It depends on how many features you want to add after we begin. It depends on how many revisions we go through.

When people ask me to set a firm deadline, I'm always tempted to ask them, vaguely, "When we don't meet that deadline, what do you want me to sacrifice?" Any deadline can be met if you sacrifice enough of the project requirements. So if we're coming up on a deadline, would you rather I miss the deadline or that I sacrifice some of the requirements? That is, let's say you want a website running with features X, Y, and Z, and we have a deadline of June 1st. The question isn't whether I can meet the deadline of June 1st. The question is, on May 31st, when feature Z isn't ready (there will be some feature set "Z" that isn't ready), do you want to go ahead and launch the site anyway? Or is Z worth holding up the launch?

In other words: project managers should should focus on priorities rather than schedule. "Being on schedule" and "being within budget" are just two more features that need to be prioritized within the set of features that a project is trying to meet.

Re:I guess I'm not an expert then.... (5, Insightful)

Sponge Bath (413667) | 1 year,10 hours | (#43530473)

I know I suck at doing development estimates.

A struggle is getting people to even agree on what a development estimate is:

Me: "That will take 2 months of development work."
[two months of interruptions, putting out fires and "prioritization" later]
Other: "Why is this not done? You suck at development estimates."

External Dependencies (2)

Bigby (659157) | 1 year,11 hours | (#43529659)

Predictions on the time it takes for me to do something can be off, but not by much. Most good predictions have contingency plans, etc...

In my experience, the biggest variability in estimates is the reliance on external dependencies. If I were the only person needed to work on something and I estimated 40 hrs of work, I would probably get it done in 30-45 hrs. But when that works requires someone else to do something at a critical point, even if it only takes 1 hr, the ability to acquire that resource in a timely manner ALWAYS messes with the time. Instead, the 30-45 hrs turns into 40-60 hrs. Amazingly, the "wait time" makes my time spent worse as well. I have to go through "ramp up" time again.

You can even schedule out that you will have the person for 1 hr a whole week ahead of time. But I have found it rare that you are able to acquire that resource remotely close to the time you scheduled.

Not completely useless (1)

rwa2 (4391) | 1 year,11 hours | (#43529663)

Well, I at least have my wife trained to treat my time estimates as "no sooner than", and I don't have any trouble sticking to those commitments. Can't be that much harder to train your boss to have the same expectations.

Anyway, isn't most of Agile centered around coming up with time estimates formed from a consensus of team members who know you well?

Re:Not completely useless (1)

Bigby (659157) | 1 year,11 hours | (#43529725)

On a related manner, if you are consistently off with those estimates, others can adjust accordingly. Two examples:

- My wife used to be typically 15 minutes off on everything. She said we'll meet at 7pm; I assumed 7:15pm. It worked like clockwork. After she realized this, she started to get better with her time and I adjusted. She actually sets her car clock 9 minutes ahead right now...

- Phone meetings at work never started when scheduled. They typically start 5 minutes late. So I started calling in 4 minutes late. I am always in before the other critical attendees and it works ALL THE TIME.

I always follow Scotty's law (5, Funny)

Capt.DrumkenBum (1173011) | 1 year,11 hours | (#43529683)

Always tripple all estimates. That way you always look like a miracle worker.

Re:I always follow Scotty's law (2, Interesting)

Anonymous Coward | 1 year,11 hours | (#43529759)

I have a PM who actually does this. He takes everyones estimate by 'pi'. He says it works and has theories why it works. But just knows it does. In my exp he is right. Someone says 'it will take me 2 hours', it will take them about 6-8 hours.

Only with the dead easy tasks are people spot on. Anything else they are usually wildly guessing. Unless they have done it before (and even then...).

Re:I always follow Scotty's law (4, Funny)

slew (2918) | 1 year,11 hours | (#43530039)

He takes everyones estimate by 'pi'....In my exp he is right.

If your PM takes somebody's imaginary estimate and multiplies it by pi and you exp it, your result will necessarily be complex, yet the error will be easy to bound with a circular range (even if with an initial wild guess)... Just say'n...

Re:I always follow Scotty's law (1)

DavidClarkeHR (2769805) | 1 year,10 hours | (#43530351)

He takes everyones estimate by 'pi'....In my exp he is right.

If your PM takes somebody's imaginary estimate and multiplies it by pi and you exp it, your result will necessarily be complex, yet the error will be easy to bound with a circular range (even if with an initial wild guess)... Just say'n...

How dare you frame a humorous anecdote in statistics, and render it completely logical and un-funny.

Re:I always follow Scotty's law (2)

mark-t (151149) | 1 year,11 hours | (#43529899)

No, actually, you look like a crappy estimator. In game development especially, projects don't typically have enough of a development budget to afford to overestimate by a factor of 3, so when you tell somebody it's going to take 3 days to do a task you think you can actually finish in one, the producer's only going to ask for a detailed breakdown and justification about why it's going to take so long... and when you end up describing how it will take several hours to implement something you should be able to do in a couple of hours, you're going to come across as incompetent, and possibly even out of a job altogether.

Re:I always follow Scotty's law (1)

Capt.DrumkenBum (1173011) | 1 year,11 hours | (#43529949)

And you look like a moron, with no concept of humour.

Re:I always follow Scotty's law (1)

Anonymous Coward | 1 year,11 hours | (#43530095)

He's probably a Star Wars fan, still recovering from Jar-Jar Binks.

Re:I always follow Scotty's law (2)

Dixie_Flatline (5077) | 1 year,11 hours | (#43530309)

Actually, doubling or tripling the estimate is USUALLY correct, the problem is that it's not correct if you apply it all at once. I've known managers that take any estimate and double it, but crucially, you don't allocate the effort all in one block.

If you need to code a widget, and it'll take you 3 days, realistically, that's just for the initial implementation. You can debug it, but that's no guarantee that it'll work as intended all the way until the end of the project. You probably have another 3 days of work to KEEP it working.

Overestimating is almost always the right thing to do, if you can get the people writing the schedule to understand that when you say six days, you mean three now and three later.

Re:I always follow Scotty's law (1)

steelfood (895457) | 1 year,11 hours | (#43530091)

So you're saying that the real date of the events in Star Trek was actually the year 6795?

Re:I always follow Scotty's law (2)

FuzzNugget (2840687) | 1 year,10 hours | (#43530391)

In not sure why anyone thinks this funny, because it's absolutely true.

No matter how much experience you have, there will *always* be that huge feature you initially thought would be a minor thing, there will *always* be those impossible-to-predict functionality hangups that take forever to solve and the client will *always* have "oh, yeah, and..." types of changes to the project requirements that completely alter the scope.

Scotty Principal... (1)

Kenja (541830) | 1 year,11 hours | (#43529703)

If you think it will take an hour, say it will that three, then when it takes two you're a genius for getting it done so fast.

Re:Scotty Principal... (4, Insightful)

Takatata (2864109) | 1 year,11 hours | (#43529753)

Than a competitor will say it will take two hours and get the job. Ok, finally it will take four hours, but still, he got the job.

Re:Scotty Principal... (1)

ADRA (37398) | 1 year,11 hours | (#43530189)

And when it invariably takes them 4 hours to implement the feature and their sales 'win' ends up costing them more than the value of the contract, natural selection works its way though and they can instead estimate how long it'll take to find a new job.

Re:Scotty Principal... (1)

ZombieBraintrust (1685608) | 1 year,11 hours | (#43529997)

But what if you think it will take an hour, say three, and then take four hours? Most people are already padding their estimates and the estimates are still low.

Alternate approach... (0)

Anonymous Coward | 1 year,11 hours | (#43529709)

From the story, "[they] were instructed to lift a long log from the ground and haul it to a wall about six feet high. There, they were told that the entire group had to get to the other side of the wall without the log touching either the ground or the wall, and without anyone touching the wall. If any of these things happened, they were to acknowledge it and start again."

Sure seems like it would have been easier to just carry the log around the wall rather than over the top.

Testing (2)

invid (163714) | 1 year,11 hours | (#43529717)

It took me a few years for me to discipline myself to including testing and bug fixes in any estimate I made to managers. When ever I would say, "I'll finish coding by X," they would always assume that it would be in release condition by then.

Is that really the problem? (5, Insightful)

Anonymous Coward | 1 year,11 hours | (#43529723)

I often find another problem is management's refusal to accept the estimate of the developer. I am usually pretty good at estimation. Here is what usually transpires for me:

Manager: "How long will it take you?"
Developer: "2 months."
Manager: "You don't have 2 months. You only have 1 month. Redo your estimate. How long now?"
Developer: "2 months."
Manager: "You don't have 2 months. You only have 1 month. Redo your estimate. How long now?"

At this point I feel like saying:
Developer: "Why are you asking for my input? Just write down 1 month. And do you want me to tell you I will be 1 month late right now or in 1 month from now?"

Re:Is that really the problem? (5, Interesting)

invid (163714) | 1 year,11 hours | (#43529779)

I was once invited to a meeting with the customer because my manager was sick. When people started talking schedule I casually mentioned the 18 months it would take to complete the software. The customer went ballistic. Apparently the schedule I gave my manager never made it to the customer.

I was never invited to a meeting with the customer again.

Re:Is that really the problem? (4, Insightful)

AK Marc (707885) | 1 year,11 hours | (#43530021)

I've run into that. "If you want the lies told to the customers to be consistent, you must identify which lies you've already told them." Management didn't like my snark, but I received a briefing before future customer meetings.

Re:Is that really the problem? (0)

Anonymous Coward | 1 year,10 hours | (#43530493)

Did they go ballistic b/c they thought they were paying for 54 months, or because you confirmed that their goal of 6 months wasn't possible?

Re:Is that really the problem? (5, Informative)

Platinumrat (1166135) | 1 year,11 hours | (#43529937)

I'm constantly getting this effect at work now. My current manager (who has no technology background or experience) is always challenging my 25+ years experience. I've already felt the pain of optimistic estimates and now include everything, requirements, documentation, design, code, integration, test, more documentation, installation, commissioning and support in an estimate.

He comes out with the following gems:

- "I believe your estimates are too high"

- "I've already committed to a delivery schedule with the CEO and Engineering Manager"

- "Well, we'll just have to challenge your assumption"

- "We'll just have to find ways to work smarter"

- "We'll just need to work extra hours then"

- "You're not showing enough committment", when asked to work on the weekend and holidays. This despite being with the same company for my entire working life

It's like I'm in a Dilbert nightmare now.

Re:Is that really the problem? (1)

Anonymous Coward | 1 year,11 hours | (#43530117)

My current manager (who has no technology background or experience) is always challenging my 25+ years experience.

This despite being with the same company for my entire working life

Already two reasons to look for a new job, then. Nothing worse than a clueless asshole overpaid manager, giving you the commitment bullshit.

Re:Is that really the problem? (0)

Anonymous Coward | 1 year,10 hours | (#43530389)

Ugh. Is this what passes for human interaction in the business world? Why did I ever think I wanted to be a programmer when I was young.

Those phrases are frankly insulting to you as a professional and a human being. That man is verbally shitting on you.

Re:Is that really the problem? (0)

Anonymous Coward | 1 year,11 hours | (#43530271)

Sorry, forgot the last part:
Manager: "You're fired".

I'm deeply confident (1)

PhrostyMcByte (589271) | 1 year,11 hours | (#43529729)

That it'll take 2x-3x longer than it takes in my head. If there are no spec changes (i can dream, right?) or other surprises, maybe put that down to 1.5x.

When given a project, I'm sure most people will have a macro-level architecture thought up within minutes. It all seems so easy at that point! If you're lucky you get to spend a little more time in thought before being asked for a time estimate. If you're unlucky, well... in those cases I just multiply by 3. Underpromise, overdeliver and all that.

Looking waaay too deep in to the issue. (0)

Anonymous Coward | 1 year,11 hours | (#43529751)

There are much more simple ways to explain this..

1. There is often no incentive to deliver an accurate projection. If the job will take 12 months, you say it will take 12 months, and your competitor says six months, guess who is going to get the bid. When the six month date rolls around, the project will be extend to 12 months anyway because there is already a lot of time and money invested. Lying works. Welcome to the bid process, and sales in general.

2. Humans are bad understanding complex, non-linear relationships. Software development is just about the definition of complex and nonlinear.

3. There is already and expectation of cost and time overruns in development projects. Most people are shocked and surprised when a project is delivered on time.

Re:Looking waaay too deep in to the issue. (1)

AK Marc (707885) | 1 year,11 hours | (#43530055)

Also, I've found a large disconnect between effort and elapsed time. It takes me 4 hours to do the work, but I need 16 hours of project meetings, so 3 days is the soonest I can get my 4 hours of work done.

management (1)

RichMan (8097) | 1 year,11 hours | (#43529775)

My team seems to do ok on the estimates. Then we get beaten into 1/2 that by management. Then in the end it takes twice as long as management expected. So the original estimate was good.

So we would be fine if only management did not try and squeeze it.

Management never accepts the "debug", "refactor" and "new feature" timelines, those are generally considered as "not needed". It just supposed to work perfectly and on the timeline they negotiated before consulting the people who would actually deliver it.

Actual article summary (2, Insightful)

Anonymous Coward | 1 year,11 hours | (#43529795)

Blah, blah, blah. Bad estimates.

Blah, blah, blah. Oh noes! Waterfall!

Blah, blah, blah. Fixed by Agile!

Not that hard (1)

Maxo-Texas (864189) | 1 year,11 hours | (#43529825)

But it's not really that hard to predict estimates where predictable and predict a reasonable time to determine if an area is predictable.

The RUP methodology is excellent for this.

1) You gather the feature set and identify the risk vs non risk portions of a project.
a) New technology.
b) Relying on develop of technology which doesn't even exist yet.
c) Performance.
2) You work on the risky items first. You do not start on the non-risk portions until the risks are mitigated.
3) Work in a time-boxed fashion. The time box can be 3 weeks or 5 weeks but deliver a working build each release. Note which features are not on track and drop them, adjust estimates, or even cancel the project.

And there is also baselining your coders. Over time, some will consistently be over cautious, under cautious, or on target. And by a consistent amount.

Let me put it this way...

How long would it take you to develop a sorting algorithm for a screen element?
How long would it take you to develop an import mechanism?

OTH, how long would it take to integrate your web site with an app using a new poorly documented library delivered last year?

I agree with the author that some things can't be estimated. But many things can.

The biggest problems I've seen are

1) Business decides the delivery date, features, and sometimes even the budget without consulting IT.
2) If a couple 70 hour weeks work to deliver in a crunch then always working 70 hours must be even better, right?
3) Business firing anyone that says a project is risky ("not drinking the koolaid").
4) This is a funny one.. They come and say, "How long will this take" and one person says 4 weeks and the other person says 2 weeks. So they consistently give it to the person who said 2 weeks. And then it takes them 4 weeks (sometimes longer).

It's not that hard (1)

Hentes (2461350) | 1 year,11 hours | (#43529837)

It's easy to manage time if you keep this simple law in mind:
The first 90% of the work will take up the first 90% of time, and the remaining 10% will take up the other 90% of time.

Re:It's not that hard (0)

Anonymous Coward | 1 year,11 hours | (#43530281)

You forgot to account for the last 120%. - Scotty

When The CEO Can Estimate Time To Profitability, (0)

Anonymous Coward | 1 year,11 hours | (#43529843)

Then I'll estimate time to design, implementation, testing, debugging, and release of a product.

How about people just stop with this ridiculous nonsense notion that it's even possible to estimate this kind of thing to +/- 1000%?

Re:When The CEO Can Estimate Time To Profitability (1)

RichMan (8097) | 1 year,11 hours | (#43529877)

Profitabily is 12 to 18 months out. Thats when the hockey stick curves up.

It was that way 3 months ago. It will be that way in 3 months.

Scotty knows (5, Informative)

u64 (1450711) | 1 year,11 hours | (#43529853)

La Forge: The Captain wants this spectrographic analysis done by 1300 hours.
Scotty: Starfleet captains are like children. They want everything right now and they want it their way.
But the secret is to give them only what they need, not what they want.
La Forge: Yeah, well, I told the Captain I'd have this analysis done in an hour.
Scotty: How long will it really take?
La Forge: An hour!
Scotty: Oh, you didn't tell him how long it would *really* take, did ya?
La Forge: Well, of course I did.
Scotty: Oh, laddie. You've got a lot to learn if you want people to think of you as a miracle worker.

- TNG 6x04

Either .. (1)

houbou (1097327) | 1 year,11 hours | (#43529873)

Use a OUIJA board, or, do some decent project management planning and know thy tasks, thy players and thy resources at your disposal.
For the most part, double your estimates and then adjust where it gets too costly and you know your players can perform fast than expected.

Scotty knew. (1)

Culture20 (968837) | 1 year,11 hours | (#43529875)

Lt. Commander Geordi La Forge: Look, Mr. Scott, I'd love to explain everything to you, but the Captain wants this spectrographic analysis done by 1300 hours.
[La Forge goes back to work; Scotty follows slowly]
Scotty: Do you mind a little advice? Starfleet captains are like children. They want everything right now and they want it their way. But the secret is to give them only what they need, not what they want.
Lt. Commander Geordi La Forge: Yeah, well, I told the Captain I'd have this analysis done in an hour.
Scotty: How long will it really take?
Lt. Commander Geordi La Forge: An hour!
Scotty: Oh, you didn't tell him how long it would *really* take, did ya?
Lt. Commander Geordi La Forge: Well, of course I did.
Scotty: Oh, laddie. You've got a lot to learn if you want people to think of you as a miracle worker.

It also helps you plan time for unforeseen setbacks.

So true (5, Insightful)

Dixie_Flatline (5077) | 1 year,11 hours | (#43529887)

I hate making estimates. I'm always, ALWAYS wrong. I always know I'm GOING to be wrong.

I've been trying to fix this for 12 years. I thought it was just inexperience talking, but I'm a grown-up programmer now. 'Senior', by some estimates. And yet I still have a hard time estimating the time of getting things up and running. I write one thing, and four things that I couldn't have anticipated crop up. This is particularly true in my industry (video games) where you're often working with an engine that's a few years old, and other people are in the middle of working on it, and specs are changing under everyone all the time. Things that look straightforward end up taking bad detours through networking components that nobody else understands because that part was written years ago and those programmers aren't around anymore.

Man, this story makes me feel a lot better about myself.

Re:So true (1)

fl!ptop (902193) | 1 year,10 hours | (#43530445)

I thought it was just inexperience talking, but I'm a grown-up programmer now. 'Senior', by some estimates. And yet I still have a hard time estimating the time of getting things up and running

You need a "rule of thumb." I had the same problem until I decided that the minimum a project would take for basic functionality is 4 hours for each table in the database. If they need fancy ajax stuff or any eye-candy, then it goes up from there.

It's worked pretty well for the past few projects. I've even come in under on a couple.

Re:I've been trying to fix this for 12 years. (1)

TaoPhoenix (980487) | 1 year,10 hours | (#43530523)

I know, insert prelim apology for sounding "arrogant" etc. Then let's thrash out a theory.

"I've been trying to fix this for 12 years." When something takes 12 years to get better at, there's hidden factors at play.

Suppose you try a thought experiment. Imagine one of your recent projects. So you get to the stage of the "estimate" (really some kind of pre-pre-pre estimate!) and imagine what you were thinking when you worked it out.

Then try to pin down at least a couple of the "oh my gawd" moments when the whole thing exploded. Clarify a little why that particular moment didn't work.

So as part of the thought experiment, the next time you get a project, make THREE estimates. (Feel free to add a couple of bonus ones). The first is private and not told to anyone. *Because you just throw an "insane" chunk of time on top of it*. Go wild! Three month project? Whee! Let's pretend it takes two years! And lo and behold, it came in at 10 months. Yay! You were "under your estimate!" That's your first private estimate - throwing so much time that it's designed to *not go over, with NO penalties*.

So then the second one should perhaps also be private - the one that made you *think* (wish?) it was three months. But that one will be too short, for all the reasons you said you've struggled in 12 years.

Then your third one is to build in contingencies for "nightmares" - "I don't know what it is yet but something awful will go wrong here."

Times three (1)

Anonymous Coward | 1 year,11 hours | (#43529891)

Real time expectation = ideal expectation times three

x1 = time you need to do the job if nothing goes wrong
x2 = when you find something unexpected and search for a solution
x3 = implementing the fix/workaround/rollback or whatever you decided to do in the end

I call this experience.

This doesn't apply to me (0)

Anonymous Coward | 1 year,11 hours | (#43529915)

First post!

I don't know what the article is talking about, my time estimates are perfect.

Meaningless Summary/quote (1)

MasseKid (1294554) | 1 year,11 hours | (#43529917)

I started to get offended at this broad generalization that experts can't make accurate estimates. And then I realized that no where in the summary does it say anything as to the absolute value of anything. It uses phrases like "extremely accurate" or "extremely confident". If someone takes a 1,000 hour project, and predicts it will take 1002 hours +/- 1 hour, is that a failure? Or does the OP mean the expert says 1,000 hour project is predicted to take 10 hours +/-1 hour is a failure. What is this confidence? Is this 99.99%? Is this 51%? An adverb and a verb without a point of reference is useless. But man, does it sure sound good!

Re:Meaningless Summary/quote (1)

ZombieBraintrust (1685608) | 1 year,11 hours | (#43530159)

I think the article is saying most people are not experts but rather confident proffesionals. They know how to do their job. They can program the thing your asking them to do. But this doesn't make them expert estimators. To estimate properly you need to be collecting data on yourself. You need to be basing your predictions on that recorded record. You need to be looking at the acuracy of your previous predictions and providing a margin of error based on data. To be a true expert that margin of error needs to be consistantly low.

Not overconfidence... Unrealistic expectations (1)

gameboyhippo (827141) | 1 year,11 hours | (#43529943)

In my previous life as a software architect for a small rural software development shop, I would try to give estimates and my bosses (all salesmen) would come back with, "I can't sell the client that!" Then when I missed the deadline or had to work weekends they were quick to blame me for giving an unrealistic deadline. My favorite line was always, "Give me an estimate, I won't hold you to it." Yeah. freakin. right.

Even better is when I would attempt to show them what other SUCCESSFUL development shops were doing. They would then give the excuse, "That's because their developers just sit and do nothing all day. Big shops have money to blow." Wrong. Big shops grow big because they know what they are doing. Eventually when they figured out my patience had run out, they dismissed this constructed advice as me just dissing the company.

I'm not sure why I stuck around with them for so long. I guess it was a sense of loyalty. Yet they tried destroying my marriage with their unrealistic estimates (and contracts that allowed clients to call me at home when-freakin-ever they freakin wanted. Guess as long as it didn't bother them or their time with their family, who cares, right?) Perhaps I just had a form of "stockholm syndrome".

My reasons why development estimates are hard (4, Insightful)

ADRA (37398) | 1 year,11 hours | (#43529969)

People estimate based on how much time they think it -should- take, but you almost never estimate:
1. External factors which grow time
2. Feature/function clarification takes time
3. Outside resource turnaround takes time
4. QA may never be satisfied
5. We're moral and WE make a lot of mistakes along the way
6. Most likely, you don't know all the caveats of developing the piece of work until AFTER the development is over
7. General personal time spent elsewhere (meetings, consulting with co-workers)

Sadly, the best estimate for completion ends up being 1.5-2x longer than my original gut check, so as long as you pad out your estimates, you should be fine.

Re:My reasons why development estimates are hard (1)

roman_mir (125474) | 1 year,11 hours | (#43530017)

5. We're moral and WE make a lot of mistakes along the way

- can I make a suggestion then, try to be less moral?

If you meant 'mortal', then try to be less of that as well.

so called 'experts' (2)

roman_mir (125474) | 1 year,11 hours | (#43529983)

The so called 'experts' are just as much experts at estimating requirements and timing as they are 'expert architects'.

Here is a thread [slashdot.org] where I argue that J2EE is a crutch given to people labelled as 'architects', turning them into typists while removing any real architectural thought from their activities. If you read through the thread you'll see some AC objecting to that notion and he does not realise that he is arguing my points there when he talks about architects.

He is mistaking what 'enterprise' means, he believes it has to do with some technology, with some instrument, a tool or a set of tools. He does not realise that 'enterprise' really means an approach, a process, set of processes and standards that a company forces itself to adhere to, be it in implementation details or documentation process (all of which are important of-course), but enterprise does not mean just some solution provided by some vendor even if it has the word "enterprise" in its name!

So with that in mind, realise that what we actually have for architects are most of the time not architects at all, they are copy pastors, they are typists, they are managers probably, but they are not actually designers.

Those are the same people that would be considered 'experts', who managers turn to for time estimates. I don't remember myself underestimating projects at all or overestimating by more than a factor of 2, because I have the entire process of what it takes to build a project in mind and I break it down into all the little pieces, put a number that comes from past experience in front of that little piece, then the numbers are added up and there is some adjustment based on the team, the people that are going to be working on this.

AFAIC overestimating is not as a big problem as underestimating but if you are bidding on a job, then it does present a challenge. In case of bidding you are actually not truly estimating a project, you are just trying to get it before the other guys get it, and I think that's where the real problem comes in. Managing client expectations is a serious matter, you better be able to do that and I think the more you way overestimate or way underestimate the less likely the clients are to trust you in the future, so be true to yourself.

But again, how can somebody be true to themselves, when they don't even understand themselves what it is they are doing in the first place?

Level of Detail (3, Interesting)

cant_get_a_good_nick (172131) | 1 year,11 hours | (#43529985)

Back when Joel spent time on writing, Joel Spolsky of Joel on software had an interesting method for doing time estimates [joelonsoftware.com] . His point was to go into a deep level of detail. Instead of handwavy "code the GUI" the only way to really get anything remotely close to a real time is to estimate everything down to at least half day, if not lower granularity. It's not the "oh you feel the time better" as much as to think of EVERYthing you need. If you go to a lower level, you may remember that dialog box that you didn't think of at the 25,000 foot level.

It would be interesting to see if anyone ever used it to improve their estimates. Even he "disavows" it now, preferring the method in his software tool. But I like the "the world is a big place, are you sure you're thinking of everything" that the older method pushed you to.

Re:Level of Detail (0)

Anonymous Coward | 1 year,10 hours | (#43530379)

He disavowed it because it simply doesn't work and never has. It's impossible to "think of everything" or rather the only possible projects where it's possible to think of everything are embarrassingly trivial. It also allows for zero changes in the design or structure along the way.

My experience (2)

pkinetics (549289) | 1 year,11 hours | (#43530037)

Something my boss has us do when we estimating projects. She has a certainty factor that we set for each task, simple terms, which equate to a percentage in her calculations. The higher our certainty, the less risk that the task is underestimated. The lower the certainty, the larger the margin that the estimate needs to be factored.

Makes a huge difference in ballparking our estimates.

Estimates don't account for Risks and Unknowns (2)

mtippett (110279) | 1 year,11 hours | (#43530053)

As per my blog post a couple of years ago at http://use-cases.org/2011/06/04/getting-good-estimates/ [use-cases.org] [use-cases.org] and http://use-cases.org/2011/06/22/updates-on-getting-good-estimates/ [use-cases.org] [use-cases.org]

Most good estimates have a range - and not a number, or a number with a confidence (both are interchangeable).

If an engineer says it will take two weeks - I push for a range or a confidence. If the range is weird (2-8 weeks), I push for the engineer to tighten their estimate through discussing or raising and discovering the unknowns or the risks that they are aware off. That sort of estimate would usually end up around 3-5 weeks which is a reasonable margin - and a lot better than than underestimating by 50%.

Same with estimates that are too narrow. "2 weeks +/- day". That implies a full level of understanding, no risk and no dependencies. Almost never happens. Work through the same risks/unknowns and the estimates usually become really bad - typically at least double of the "high confidence" estimate - similar to TFA.

There is a lot of reasonably applicable theory behind this (confidence intervals, cone of uncertainty, etc). But we don't necessary focus on mastery of our art...

Some overlooked bullet points (2)

Roachie (2180772) | 1 year,11 hours | (#43530061)

3 days for bitching, pissing and moaning.
3 days for dicking around on the interwebz
1 day lunch overages.
2 days for "zoning out"
3 days for witty banter.

That's why we use models (0)

Anonymous Coward | 1 year,11 hours | (#43530097)

This is why in scientific disciplines we look at predictions from models (or theories or whatever), rather than predictions from people.

So I guess if you want to make predictions about how long it takes to write a piece of software, you use the prediction of a model that has proved to be pretty good at predicting how long it takes to write other software.

Here's how it really works (1)

Ol Olsoc (1175323) | 1 year,11 hours | (#43530101)

People setting around the meeting table.

Suit: "How long do you estimate development will take on this project?"

You: "My best estimate is 2 years, 3 months, as long as specs don't change."

Suit: "But the customer would like the product in a year"

Bean counter: We'll need 6 months to determine the task flow".

You: Then you'll need to add six months to the scehdule."

Suit: Okay, it's settled. We'll start tommorrow, the accountants will take the first six months to determine the charge numbers, and the programmers will have the job finished six months later.

Two days later.....

Suit drops by....p> Suit: "Hey, I just got off the line with the customer, and they changed all the specs. Don't worry though, I told them there wouln'd be any impact on the schedule. Oh, by the way, the accountants say they need another month. But I every confidence in you.

a year and a day later.........

Annoyed suits and accountants sitting around the meeting table...

Suit: Okay, now what the hell is the problem here?

You: We only had five months to complete the task, and specs and accounting time were all changed..

Suit interrupts: You told us you could have it finished, you aren't going to make it very far here - we need better estimates on your part!"

You: Sigh... Well, I think if we work everyone double shifts, we can get it out the door in anotther two months"

Bean Counter: We'll need a month to redistrubute gharges and funds."

You: "Wait! umm.."

Suit interrupting: Okay, that settles it. A month and a half out the door, just like you promised. And don't let me down, again. Just what to you programmers do with all your time anyway?

Estimate failure (1)

ADRA (37398) | 1 year,11 hours | (#43530113)

During my last project, one component was estimated (by others) at 2 man months, and it ended up taking 6 full time developers a year to implement. The estimates were absolutely horrible. As much as it was the fault of the original estimate, management constantly rode the development team to get it done asap, which probably in the end did more harm than good.

I give perfect estimates, every time. (0)

Anonymous Coward | 1 year,11 hours | (#43530125)

I give perfect estimates, every time. It's the honest truth.

Then the project manager(s) squeal like stuck pigs when they see them and force me to cut them down to what they think is reasonable.

That's why your software is late and buggy.

Re:I give perfect estimates, every time. (1)

maxwell demon (590494) | 1 year,10 hours | (#43530433)

The key to perfect estimates is to not use wall time, but events:

"How long will it take you to do this project?" - "Until it is finished."

Unfortunately very few manages will like that answer ... :-)

Impossibru! (0)

Anonymous Coward | 1 year,11 hours | (#43530141)

If you've ever had to deal with ExpressionEngine and it's complete ass-backward "parsing order" crap, you know that giving good estimates is impossibru!

This is doubly hard for consultants (2)

linuxguy (98493) | 1 year,11 hours | (#43530161)

When my customer comes to me and asks me to provide an estimate for a job, if I give them a conservative estimate, some of them may think that I am milking them with the extra hours. Specially if they get a competing estimate from an overly aggressive Indian company who is eager to sign the contract but has no clue on how to deliver.

I usually do not fret too much about customer feelings in a case like this. But during slow times I have little choice. Bottom line is, most of us would love to provide conservative estimates, but often times it is not as simple as that.

Mandatory Bad Estimates (0)

Anonymous Coward | 1 year,11 hours | (#43530163)

There is another reason time estimates are bad -- they are often required to be bad to satisfy management. In my 25 years of experience I've often come up with reasonably accurate time estimates. These are invariably too long for management to accept. Therefore, management often picks someone else (with a lower estimate) to lead the project, and then the project comes in late, usually around my original estimate. I've also found that explaining why my estimates are so high does not help. If I set aside project time for investigation, research, and other non-specific tasks that my experience tells me is necessary, it doesn't make a very good story. Most management will go for the happy story, and then deal with the repercussions.

Estimate = Deadline (0)

Anonymous Coward | 1 year,11 hours | (#43530209)

At my giant corporate place of employment, developers are pressured into giving optimistically conservative estimates. They are called estimates and everyone plainly knows that they are estimates of unknown quantities. These estimates are entered into Microsoft Project and the dates are manipulated to fit whatever deadline has been set. That Project file is then sent upwards into the management cloud from which threats and curses come back down when the dates aren't met. The reality that no one talks about is that there is no such thing as an estimate here - only commitments and deadlines. But they pay me, so I will be back tomorrow.

There was this company that wanted a project ... (2)

Skapare (16644) | 1 year,11 hours | (#43530241)

... to be developed for them in 3 months. I estimated 10 months. So they decided to look around for another developer. A couple years later they came back and asked if I could do it in 6 months. I told them it would take 12 months, now.

Confidence (1)

Todd Knarr (15451) | 1 year,11 hours | (#43530277)

You can have confidence in your estimates and still be aware that that confidence is misplaced. One of the common things I keep saying to my manager is "Yes, I'm pretty sure we can finish this in 3 weeks. But I want to schedule it for 6 because always, always we spend half our time getting pulled off onto other things and I want to account for that now before we get in a bind.". I have confidence in my estimates, but I also have confidence in the statistical evidence of how reality varies from my estimates and I'm not prepared to ignore the latter.

As others have said, I also end up in arguments where people "up the chain" have already decided when they want something delivered and are pressuring me to make my estimates conform to the schedule they've already set. I don't consider this a problem with my estimates or my planning/scheduling, because I have no input into this or ability to control it. The problem lies with the people who're making promises without making sure those promises can be made good on, who then expect someone else to pull their chestnuts out of the fire. I can't do anything about that, because I can't order them to ask for estimates before setting delivery dates.

I don't suck, time estimates are inherently hard (0)

Anonymous Coward | 1 year,11 hours | (#43530301)

The agile software methodology was created in large part to address this problem (and the related problem of budgeting) and it works by saying, "we're only going to estimate what we can do in the next month."

You may have to evaluate a library or a technology to see if it's suitable, you might have to come up to speed on something, and you will often be waiting on another component to complete.

The biggest issue, though, is that clients don't know what they want until they see it. So if I take vague requirements X, Y and Z and generate X', Y' and Z', the client might decide he really wanted A, B and C. How can I possibly estimate that? And any client who promises he won't change his mind is lying.

The only reason people deliver even close to the estimated date is because they will throw in massive numbers of hours trying to meet these arbitrary deadlines, or cut corners or whatever.

Uh no... (5, Insightful)

Charliemopps (1157495) | 1 year,11 hours | (#43530303)

My estimates suck because:

Project leader: Ok, so we need to know how long it will take for you to do X
Me: I'm not sure, that's an entirely new API, proprietary to the vendor, there's almost no documentation and their website has a support forum filled with questions and basically no replys to any of them.
Project leader: Well, we need a number.
Me: Why?
Project leader: I have to fill in this box here... see?
Me: Ok fine, 800 hrs
Project leader: Now hold on a minute, this wont take 800hrs
Me: It could, I have no idea. It's already taken the majority of at least one hour and I don't even know what language it's in.
Project leader: Fine, I'll put down 800hrs, but you're the one that's going to look silly.

Project leader: I can see here your original estimate was 800hrs, and your actual billed time was 1265hrs. What causes led to you missing your estimate, and how can we avoid those in the future.
Me: Don't make estimates.
Project leader: Come on now, I need a real answer.
Me: Why?
Project leader: I have to fill in this box here... see?
Me: ....

Double the time is suprisingly accurate (0)

Anonymous Coward | 1 year,10 hours | (#43530361)

And that's double the time you THINK it will take to complete.

It almost NEVER manages to get within time, but it never seems to take more than double (unless it turns up as a doomed project very early on and you can SEE it won't finish anywhere near the time.

I.e. you forget about commenting the code, or the tests take longer to collect all together, or some bit of new language feature *reads* like it'll do X, but it really does Y instead, or the X isn't really what it was meant to do, so is harder to implement than you thought.

This works up to one-man-month (or so) work.

Problems and Estimatated Solution Times (1)

jfz (917930) | 1 year,10 hours | (#43530417)

Estimates seem to be driven mostly by the following forces:

Non-Tech Problem Space

In the worst case, this is the equivalent of walking up to a student and asking how long it will take them to solve a problem in both a subject he/she hasn't studied yet, and in a problem with no similarity to those at hand. Any notion of accuracy gets thrown out the window under these conditions.

Tech Problem Space

What tech is needed? And how long will it take to acquire proficiency in this tech? Since tech is a road well traveled by others, this makes the estimation of the learning curve and the tech application easier.

I think the answer lies in patience, instead of demanding estimates that can be produced in the next hour. In many cases, the problem needs to be inspected and possibly specified further to come up with anything approaching accuracy. I have to wonder if this is something that is understood and being communicated effectively to non-engineers and those on the client side. Nevertheless, if businesses chooses to subjugate informed, honest estimates to salesmanship, then none of this matters anyway.

propose projects substantially already done (1)

peter303 (12292) | 1 year,10 hours | (#43530435)

We did that in the college research game. A prototype was already done before we applied for a grant. We used the money to perfect the old project and start a new secret project. Nothing succeeds like existing success.

Estimation is a losing game. (1)

idontgno (624372) | 1 year,10 hours | (#43530453)

Think about it.

Time is, for all practical purposes, linear. Your task will take a specific quantity of time to complete. You don't know that quantity of time in advance, because you don't control all factors, so you're guessing.

Now, what is the environment of your guess? You are trying to pick out a specific point in the future at which your task will be done.

Balance that against the infinite number of points of time in the unbounded future in which your task could actually be completed in.

1 estimated point against an infinite number of possible points. That's your odds of picking the CORRECT point in the future. 1 divided by infinity. Although it's not necessarily mathematically correct, it's a useful convention to reduce that expression to "0". And that is your precise odds of estimating the completion time correctly. Zero.

A very simple method that works (1)

gnasher719 (869701) | 1 year,10 hours | (#43530463)

Here's how you do it: You split your development task up into small parts that should take 1 to 5 days. For each task, you write down your best estimate. Now of course you know you are bad at making good estimates, but that doesn't matter: You do the first part, then write down what you estimated, and when you actually finished. From that you extrapolate when you will finish - if you estimated two days and it took three, you estimate that the whole task will take 50% longer than estimated. After the second part is finished, you get an improved estimate, and so on.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account