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

291–300 of 324 posts

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

#291

Post by SketchySeaBeast »

karthikb wrote: post #289
SketchySeaBeast wrote: post #225

Earlier quoted context omitted.

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

Half day items were strictly bound, well know problem, like a label change, or a piece of functionality I knew by heart to be that size. I found that those items usually helps balance out the larger item misses.

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

#292

Post by flukus »

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…

It's this part where the estimate becomes a deadline:

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

> pointing out dependencies the Dev appears to not have considered.

I'm not sure if they're dependencies or other priorities in this case. I've had managers before ask for an estimate and and I've given them one (2 days), then they've assumed that I'm dropping everything I'm in the middle of and told clients it would be done in 2 days.

The problem with estimates is that the people asking for them really want promises.

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

#293

Post by Aeolun »

singingfish wrote: post #133
Aeolun wrote: post #79

Earlier quoted context omitted.

> 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.

Or, how to make people impressed by the fact that you’re always 10 times faster than your estimates.

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

#294

Post by Aeolun »

mcherm wrote: post #141
Aeolun wrote: post #79

Earlier quoted context omitted.

> 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.

> 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. I like to handle this problem by providing an estimate RANGE.

That doesn’t really matter. In these cases you often have information akin to ‘we want a webshop’, so you estimate something more or less reasonable, then a few weeks later you find out they actually meant ‘we want a duplicate of Amazon’.

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

#295

Post by aaaaaar »

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…

Thank you for posting this - I took this quiz a few years ago in a team exercise and all of my answers were off. Since then I wanted to find a copy of this test, but didn't know where to look.

I think out of 15 people nobody got more than 1 or 2 right, except for my manager, who somehow got about 8 right. I'm curious how the HN crowd does on this - care to post your scores?

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

#296

Post by jdsully »

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…

Why not just fix the lib?

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

#297

Post by caseymarquis »

wellpast wrote: post #190

> Instead, figure out which tasks have the highest uncertainty – those tasks are basically going to dominate the mean time to completion. From the technical side of things, uncertainty can mean a few things here: (A) I've never done this kind of task (or I don't remember or didn't write down how long this task took in the past) (B) I don't know how to leverage my historic experience (e.g., implementing an XYZWidget i…

If the task is to reverse engineer an undocumented binary communication protocol to replace a poorly implemented proprietary file server, building the UI isn't the portion with high levels of uncertainty. I think the advice was good.

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

#298

Post by bunderbunder »

karthikb wrote: post #289
SketchySeaBeast wrote: post #225

Earlier quoted context omitted.

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

The answer to that question depends heavily on the duration and nature of your planning iterations.

If you're doing quarterly planning, the difference between half a day and a couple a days is meaningless, and there's not really any point in distinguishing among them.

If you're doing 1-week sprints, the difference between half a day and a couple days is enormous, and the product planner might get some value out of distinguishing among them.

If you're following a more kanban-y approach, the difference is perhaps meaningful, but not particularly actionable, so I think I (personally) still wouldn't bother to capture the distinction for planning purposes.

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

#299

Post by bostonvaulter2 »

rainhacker wrote: post #265
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.

Ah, but how do you know what stage of the software project you're in? Are you 3 months into a 4 month project or are you 3 months into a 5 year project?

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

#300

Post by hnzix »

growtofill wrote: post #270
jspash wrote: post #14

Earlier quoted context omitted.

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.

> work expands to fill the time available for its completion

Oh, so if I estimate every task as 1 minute I'll finish really quickly?

The 2.4x is to overcome one's innate overoptimism (even if you see yourself as a pessimist), and to add contingency for unplanned complexity, bugs and general overhead.

It's a rule of thumb, not an immutable law, so if one has completed a similar task many times then less padding is needed.

Post reply on HN