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

131–140 of 324 posts

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

#131

Post by singingfish »

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 like to mess with people. "It's 80% done so there's only 80% left to go". "Now' it's 90% done so there's only 90% left to go" etc. Of course my current project is rather higher stakes than usual, so I'm being a little bit more sober than I normally would be. However I am emphasising the need for communication with other stakeholders and identifying and trying to rectify where they are bottlenecks pdq.

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

#132

Post by jshowa3 »

golergka wrote: post #86
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:…

> Does it all take that long? That's just a question. Asking questions is OK. If you have such a high need to please other people and such a low self-confidence that you will change your answer simply if someone asks you twice, that's the problem with you, not them. I say it as someone who have been like that and have changed it through therapy. I was a nervous mess and always thought that people around me don't like…

It actually is a problem with them because when someone asks "Does it really take that long?", they're implying that it shouldn't. Of course, in reality, they have no idea either and if they're asking you how long it should take, they should accept your answer, not try to weasel out less time.

But are they ever going to admit that they have no idea and accept your estimate on face without playing BS mind games? Probably not. But for some reason that doesn't stop them from trying.

I've never seen someone try and do this with a home contractor.

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

#133

Post by singingfish »

Aeolun wrote: post #79
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…

> But when you advocate clearly for your needs as a professional, people are generally reasonable. This has not been my experience. People want ‘estimates’ at all costs, tell you to not worry about any accuracy, and then a week later tell your manager you committed to x date.

That's easy. Guess a number. Add some units. Double it. Double it again. Then double it again. Add a zero. Done.

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

#134

Post by Sahhaese »

oli5679 wrote: post #37

In the UK, bookmakers offer 'accumulator' bets, where a punter can select many outcomes, getting a big prize if 100% correct. This takes advantage punters' failure to accurately multiply probability - 10 events with 80% probability have joint probability Something similar happens with planning, where people fail to compound many possible delay sources accurately. Dani Khaneman covered this in Thinking Fast and Slow,…

It doesn't take advantage in the way you say because you get paid along the same lines. If you bet an accumulator with 2 selections at evens, you get paid at 3/1. (4.0 decimal odds) so that is "fair".

It's profitable for bookies because they have a house edge, and that edge is increased the more subsequent bets you make. The house has more edge with an accumulator than a single bet.

People like to do accumulators because it's more meaningful to win large amounts occassionally than more regularly win less meaningful amounts.

So it's a "trick" to simply increase gambling.

If you had to pick out 8 evens shots in sequence and intended to roll over your bet each time it would have the same effect / outcome, but starting with a pound by the last bet you're effectively placing a 128 quid bet on an evens money.

It's not that the player thinks that they have a better chance of winning than 1/256 it's that it effectively forces them to gamble a lot larger amount in the situations where only 7 out of 8 of their picks come in.

And that's before considering the edge. If we consider that these are probably events that happen more like only 45% of the time (at best) then instead of a 255/1 shot we're looking at 600/1 shot.

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

#135

Post by Chris2048 »

I'm sorry to contribute to the dogpile effect (long thread probably says same thing I'm about to say, but I didn't see it..), but..

devs estimate known risks. Ideal path + predictable delays. The further reaches of the long tail are the unknown risks.

known risks are estimated based on knowledge (hence, a question for a dev), unknown risks are just an adjustment parameter on top of that estimate, possibly based on historical evidence (there is no reason a dev could estimate any better).

It should be managements job to adjust a dev estimate. Let's be real here - I've never heard a real life example of management using stats for this kind of thing, or being enthusiastic about devs doing the same.

Perhaps if management is taken seriously as a science, things will change, but I doubt it.

Bizness is all about koolaid-methodology-guru management right now, very much the bad old ways - a cutting example of workable analytical management would be needed for things to change, but this is unlikely as all the stats people are getting high pay cool ML jobs, and aren't likely to want to rub shoulders with kool-aider middle managers for middle-management pay..

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

#136

Post by crazygringo »

thatoneuser wrote: post #8
hnzix wrote: post #5

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

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 then that seems to work but you add plenty of tests and documentation to make sure it works that way in prod too and not just on your dev machine.

I don't see what that has to do with learning from previous mistakes. Pretty much all but the most basic programming turns out to be like that -- dealing with unforeseeable and undocumented problems.

(The 20% is because you weren't planning for sick days, an unforeseen emergency bugfix on another project, nobody remembered about the afternoon retreat next week, etc.)

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

#137

Post by apaatsio »

ajuc wrote: post #21
leethargo wrote: post #17

Earlier quoted context omitted.

The above approach uses the factor 2.2. Why would your factors be any better?

Nitpick: x * 2 * 1.2 == x * 2.4, not 2.2

Extended nitpick: Technically, they only said "then add 20%". They didn't specify of what that 20% is. It's up to interpretation whether they mean 20% of the original value or the doubled value.

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

#138

Post by hannasanarion »

thatoneuser wrote: post #8
hnzix wrote: post #5

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

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%?

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

#139

Post by bunderbunder »

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 have independent value. If they form a series of iterations, don't make any assumptions about whether you'll ever even get around to anything but the first one or two. That just compromises your ability to treat them as independent projects, and that creates risk that you find yourself having to worry about sunk costs and writing down effort already expended when it eventually (and inevitably) turns out that you need to be shifting your attention in order to address some unforeseen business development.

At the start of every quarter, the team would commit to what it would get done during that quarter. There were some guidelines on how many small, medium or large projects they can take on, but the overriding principle was that you should under-promise and over-deliver. Lots of slack (1/3 - 1/2) was left in everyone's schedule, in order to ensure ample time for all the small urgent things that inevitably pop up.

There was also a log of technical debt items. If the team finished all their commitments before the end of the quarter, their reward was time to knock things off that list. Best reward ever, IMO.

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

#140

Post by analog31 »

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:…

And this conversation is happening in a two hour stand up meeting with a dozen people including upper managers.
Post reply on HN