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

Why software projects take longer than you think – a statistical model

erikbern.com

Post reply on HN
Print view View original

261–270 of 324 posts

Re: Why software projects take longer than you think – a statistical model

#261

Post by jfehr »

mbesto wrote: post #184

As always, my favorite article on this subject: https://www.lesswrong.com/posts/CPm5LTwHrvBJCa9h5/planning-f... > A clue to the underlying problem with the planning algorithm was uncovered by Newby-Clark et al., who found that Asking subjects for their predictions based on realistic “best guess” scenarios; and Asking subjects for their hoped-for “best case” scenarios . . . . . . produced indistinguishable results. >…

Daniel Kahnemann calls this the "inside view" and "outside view", from his book Thinking Fast and Slow.

The relevant excerpt (mostly an anecdote that serves as an introduction to a whole chapter about it) can be found here: https://www.mckinsey.com/business-functions/strategy-and-cor...

Re: Why software projects take longer than you think – a statistical model

#262

Post by commandlinefan »

afarrell wrote: post #247
commandlinefan wrote: post #158

Earlier quoted context omitted.

> Negotiation about scope. I used to work for an online travel site - before every project kicked off, the business analysts would produce requirements documents that always started with a "flexibility matrix". The flexibility matrix had three rows labeled "schedule", "scope", and "resources" and three columns: "flexible", "moderately flexible" and "inflexible" and they were supposed to check one option for each row.…

Wait, how are resources flexible here? You can’t just scale the number of engineers on a project quickly..

We actually tried asking for more resources when the schedule was in "jeopardy" and were told that there weren't any available. They suggested we try working weekends to make up the shortfall.

Re: Why software projects take longer than you think – a statistical model

#263

Post by mntmoss »

afarrell wrote: post #218
agumonkey wrote: post #166

Earlier quoted context omitted.

I wish school taught me how to do your first point. People talk about project management, gantt diagrams and all that but you have no idea how to estimate even grossly the complexity of a thing.

The lack of a good “intro to task and small project management” MOOC or book is a serious problem for our industry’s ability to onboard junior engineers. I wish I knew how to write one, but TBH I don’t know any principles myself except one. Lots of people say “just do it and multiply by 3” without appreciating that The important part of estimating tasks is coming up with the task breakdown and identifying the risks.

The best you can do in most scenarios is to research comparable projects and calibrate against them. "They shipped in six months, therefore we can ship in six months."

Re: Why software projects take longer than you think – a statistical model

#264

Post by rainhacker »

JabavuAdams wrote: post #253

My empirically-confirmed heuristic is that the time to deliver a feature set that someone would actually want to use is 2.5x-3x of the time I think of when asked for an off-the-cuff estimate. Basically, multiply initial estimate by a number between e and pi -- no joke! It's a bit of a problem given that PM's think they're being generous with a 20% pad.

I can relate to your heuristic. The current project I've been working on is close to completion and somewhere between 2.5-3x of its initial estimate.

Re: Why software projects take longer than you think – a statistical model

#265

Post by rainhacker »

basetop wrote: post #114

The mythical man month ( required reading for most CS programs ) goes into a historical and production aspect of why software projects take longer than what you think and what you expected. Also, there is a law named after author called the Brooks's law : "adding human resources to a late software project makes it later" https://en.wikipedia.org/wiki/Brooks's_law In most industries, if you are running behind schedule…

Given most software project estimations are off, wonder if a corollary of Brook's law can be - don't add resources in later stages of 'any' software project.

Re: Why software projects take longer than you think – a statistical model

#266

Post by afarrell »

mntmoss wrote: post #263
afarrell wrote: post #218

Earlier quoted context omitted.

The lack of a good “intro to task and small project management” MOOC or book is a serious problem for our industry’s ability to onboard junior engineers. I wish I knew how to write one, but TBH I don’t know any principles myself except one. Lots of people say “just do it and multiply by 3” without appreciating that The important part of estimating tasks is coming up with the task breakdown and identifying the risks.

The best you can do in most scenarios is to research comparable projects and calibrate against them. "They shipped in six months, therefore we can ship in six months."

Have you ever done this and had it turn out successfully? Because my intuition is screaming at me that this would be disastrous.

For one, it skips the step where you break down the tasks. For another, it seems likely to ignore a bunch of variables in the search for something similar enough.

Re: Why software projects take longer than you think – a statistical model

#267

Post by pwenzel »

bunderbunder wrote: post #139

I've been one place that I thought was really good at software estimation. Their system was: Everything gets a T-shirt size. Roughly, "small" is no more than a couple person-days, "medium" is no more than a couple person-weeks, "large" is no more than a couple person-months. Anything beyond that, assume the schedule could be unbounded. Figure out how to carve those into a series of no-larger-than-large projects that…

The "small", "medium", "large" approach sounds a bit like the one used in Pivotal Tracker.

Re: Why software projects take longer than you think – a statistical model

#268

Post by jolmg »

SketchySeaBeast wrote: post #238
jolmg wrote: post #228

Earlier quoted context omitted.

"Scientific Wild Ass Guess" sounds better? I think I'd just stick with "educated guess". I wouldn't even make an acronym out of it.

"SWAG" sets the expectations much better than "educated guess"- you're saying "I got very little idea, but you really want a number, so here's a number". "Educated guess" sounds much more like you've got a good idea, which using the term "SWAG" is trying to avoid.

> I got very little idea, but you really want a number, so here's a number

Where does the "Scientific" come in? Because I really thought it implied having a good idea, which made SWAG seem like an oxymoron.

Re: Why software projects take longer than you think – a statistical model

#269

Post by SketchySeaBeast »

jolmg wrote: post #268
SketchySeaBeast wrote: post #238

Earlier quoted context omitted.

"SWAG" sets the expectations much better than "educated guess"- you're saying "I got very little idea, but you really want a number, so here's a number". "Educated guess" sounds much more like you've got a good idea, which using the term "SWAG" is trying to avoid.

> I got very little idea, but you really want a number, so here's a number Where does the "Scientific" come in? Because I really thought it implied having a good idea, which made SWAG seem like an oxymoron.

I believe it's juxtaposition for comedic effect.

Re: Why software projects take longer than you think – a statistical model

#270

Post by growtofill »

jspash wrote: post #14
hnzix wrote: post #5

My rule of thumb: take your estimate, double it, then add 20%. I'm not joking.

A professor of mine at university taught us the same thing. It's one of the most valuable things I learned and it is uncannily accurate. Even after 30 years in industry I still fall back on this formula with great results. Sadly, managers want to believe that you put more effort into estimating deadlines so I'll just whip up a gannt chart retroactively based on the 2/20 rule and they're happy.

> Even after 30 years in industry I still fall back on this formula with great results.

Isn't this Parkinson's law in action, i.e. work expands to fill the time available for its completion? That would mean you overestimate up to 2.4x each time.

Edit: math.

Post reply on HN