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

281–290 of 324 posts

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

#281

Post by afarrell »

squarecog wrote: post #280
koonsolo wrote: post #59

Earlier quoted context omitted.

> They probably don’t want you to lie, but there is a small chance that they pruessure you to. In my experience, most of the time there was pressure. I remember a funny conversation between my project manager and a colleague: PM: "We need to have X as soon as possible, how long will it take you?" Dev: "Oh that's, easy, I can finish it tomorrow." PM: "Tomorrow??? That's impossible, because it needs a and b, no?" Dev:…

Can you explain which part, in your opinion, is facepalm worthy? In your example conversation, the developer starts off by demonstrating that they are not good at thinking through how long things take them, by giving an impossibly optimistic estimate. Even the PM, whose job is not to figure out how to build stuff or how long building stuff takes, knows the estimate is wrong, and pushes back on it, pointing out depend…

> can't be bothered

or who doesn't know that "I'll need some time to get back to you on that" is an acceptable part of their vocabulary.

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

#282

Post by joshdance »

artworx wrote: post #150
undergrowth54 wrote: post #29

An important aspect of being a professional software engineer is having the backbone to sometimes say things like: - “I don’t know yet enough about the problem to give you even a rough estimate. If you’d like, I can take a day to dig into it and then report back.” - “This first part should take 2-3 days. 5 on the outside. But the second part relies heavily on an API whose documentation and error messages are in Chine…

I highly recommend the book "Software Estimation: Demystifying the Black Art". I work for an outsourcing company and part of my job is to come up with estimates and it helped me deal with clients and managers. The book contains a quiz that we used as part of a training exercise with management and the results were hilarious. Here is an online copy: https://scrumandkanban.co.uk/how-accurate-are-your-estimates... pleas…

link to the book - https://amzn.to/2IpTNw2

Going to read it. thanks.

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

#283

Post by mikekchar »

ska wrote: post #256
piccolbo wrote: post #231

Earlier quoted context omitted.

The central limit theorem is in the limit for the number of variables in the sum approaching infinity. In the finite world, the article explains how it's done. The article is saying, the sum of lognormals is not normal. You are saying: take enough of them and it is normal. The article is still more accurate than your reasoning for 30 stories. From the wikipedia entry for Central limit theorem " As an approximation fo…

You are saying: take enough of them and it is normal. This doesn't completely undermine your point, but that isn't what they are saying, I think. I read it as saying by CLT that the estimates of the mean of those distributions is normal and centered on [the mean you are actually interested in]. Tails are perhaps somewhat a red herring here, because you don't really care about them unless you are specifically trying t…

Yes, that is correct. It's been a very long time since I studied statistics, so I'm not sure if the variance of a mean has the same confidence interval as the mean. I suspect not. So you would indeed need to have a very large number of samples to get good error bars. It's a good point which I hadn't really considered. However it will never really get that far anyway because hopefully you'll intervene before the long tail hits you.

I think those really long tails are more of a problem when you are working with "features" that are much longer. If you have 1 day stories and you've been working on the story for a whole week, you know you have a massive problem. It's time to back up and see if there is a way to break it up, or to do it differently.

If you have a feature that is a month, by the time you get to 5 months, you have so much capital invested in the original plan that it's very hard (politically) to say, "Nope... this isn't working out. Let's try something else". Of course, it is very hard to get your organisation to plan to a 1 day level of granularity.

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

#284

Post by slavik81 »

koonsolo wrote: post #59
undergrowth54 wrote: post #29

An important aspect of being a professional software engineer is having the backbone to sometimes say things like: - “I don’t know yet enough about the problem to give you even a rough estimate. If you’d like, I can take a day to dig into it and then report back.” - “This first part should take 2-3 days. 5 on the outside. But the second part relies heavily on an API whose documentation and error messages are in Chine…

> They probably don’t want you to lie, but there is a small chance that they pruessure you to. In my experience, most of the time there was pressure. I remember a funny conversation between my project manager and a colleague: PM: "We need to have X as soon as possible, how long will it take you?" Dev: "Oh that's, easy, I can finish it tomorrow." PM: "Tomorrow??? That's impossible, because it needs a and b, no?" Dev:…

> That is perfect! The customer wanted to put in production on Monday, so we can now confirm.

Here you can see the exact moment when an estimate became a commitment.

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

#285

Post by thatoneuser »

crazygringo wrote: post #136
thatoneuser wrote: post #8

Earlier quoted context omitted.

Eh. I've been successful adding 20% in. I feel like if you have to double first (meaning your end result is 220% of what you originally estimated) then you aren't learning from previous mistakes. Maybe 220 is appropriate for the first time you do work or work with a certain team tho.

> then you aren't learning from previous mistakes ??? The doubling-it is for when you build the whole component on top of a library, then discover that the library has a fatal bug you can't work around, and you have to rebuild the whole component on top of a different library, then discover that other library has another fatal bug, so now you need to include both libraries with logic around when to use which one, and…

Yeah and I've been pretty good at estimating what to expect. I mean you'll always find surprises but personally I'm more inclined to quote a lower estimate and come back explaining the situation than to overcharge. But if you know of any clients who are throwing money around like that I'll gladly accept your 220% estimate for a few referrals ;)

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

#286

Post by thatoneuser »

Roark66 wrote: post #173
nnq wrote: post #52

Earlier quoted context omitted.

220% also works fine if each one of the projects is "practically unique" to you / the team... this happens >50% of the time in the real world, imo, because some fields have very little transferable skills/experience from project to project... a large percent of stuff is genuinely new every time and never repeats even if it's "basically the same thing as that other project"! (Or team composition changes.) Problem is t…

>Then finally you can say with a straight face that 20% of estimated time is for unforseen circumstances. This is how I always have done it across multiple jobs and I always called that extra contingency. Depending on the project I sometimes had to ask for over 50% of the total as contingency. If anyone queried it I would explain that it is very likely we'll need it based on my experience of many other projects. Then…

That's a smart way to do it. I used to put in ranges (basically contingency) of rate but I found myself consistently hitting a similar % of the higher estimate and just started quoting the higher estimate with the expectation that I'm not a God and there may be unknown factors which could add in more cost. Usually people are happy as you say if there's trust and you show progress.

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

#287

Post by thatoneuser »

hannasanarion wrote: post #138
thatoneuser wrote: post #8

Earlier quoted context omitted.

Eh. I've been successful adding 20% in. I feel like if you have to double first (meaning your end result is 220% of what you originally estimated) then you aren't learning from previous mistakes. Maybe 220 is appropriate for the first time you do work or work with a certain team tho.

Wouldn't it be 240%?

No he said double or (200) then add 20 (220). Unless there's ambiguity I'm not seeing.

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

#288

Post by kqr »

maltalex wrote: post #169
acd wrote: post #18

US navy has developed something similar with beta statistical distribution. You estimate "Optimistic", "Most likely" and "Pessimistic" time estimates for each task in the project and then use beta distribution on it. Some tasks take way longer than estimated. Here is the link to the time estimation described above with Beta distribution. https://www.isixsigma.com/methodology/project-management/bet...

I find this approach very interesting, but it hinges on the assumption that project completion times follow a beta distribution. What's the basis for that?

It may reflect the observations in OP kind of well -- with one difference: it assumes we're good at estimating the mode, not the median. But other than that, within the range we're talking about (1 The three things that still bother me about that idea are:

1. I haven't tried fitting it to the dataset in OP;

2. It's bounded to the right, which seems unrealistic;

3. I haven't come up with intuitive interpretations for the alpha and beta parameters in this context. If the beta distribution means something, then its parameters must have natural interpretations as well.

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

#289

Post by karthikb »

SketchySeaBeast wrote: post #225
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…

> 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. That's pretty much exactly what I've ended up using on past projects - a little more fine grained (start at a half day, went up to months), but that was my approach as well, and if I didn't know everything it went up a size.

Did you find much differentiation between half day and couple of days? Especially because some things that might take a couple days end up taking 30 mins (some efficient package already exists), and some half day things end up taking a couple days, so it comes out in a wash?

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

#290

Post by Aeolun »

eikenberry wrote: post #260
afarrell wrote: post #108

Earlier quoted context omitted.

For more on this sort if thing, Patrick McKenzie’s writing is good: - https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr... - https://www.kalzumeus.com/2014/04/09/what-heartbleed-can-tea...

> In the real world, picking up a new language takes a few weeks of effort and after 6 to 12 months nobody will ever notice you haven’t been doing that one for your entire career. Spoken as someone who has never taken the time to fully master a programming language and, from the sound of it, has never worked with someone who has either. The difference between someone who has spent 6-12 months with a language compared…

In my experience, having mastery over one language translates more or less directly into being at least journeyman in all others.

If you are working with an apprentice, whatever you do, it will seem like you are really experienced.

Post reply on HN