Planning and estimating large-scale software projects • Hacker News Board

Re: Planning and estimating large-scale software projects

#31

Post by marcosdumay » Wed, Jul 21, 2021, 5:11 PM UTC

ngrilly wrote: post #22

> It also tells us how many team-weeks this fictional, idealised project would require [...] by adding all the estimates together. I would be wary with just "adding all the estimates together". That's because we tend to estimate the median or the mode of the task duration, and not the average. Means can be added together, but not medians.

> Means can be added together

Is the error distribution of task size estimations normally distributed? Because I do really expect it to have a fat tail, and if it does, you can't add means either.

Re: Planning and estimating large-scale software projects

#32

Post by NikolaNovak » Wed, Jul 21, 2021, 5:16 PM UTC

marcus_holmes wrote: post #28

commandlinefan wrote: post #7

Earlier quoted context omitted.

> I popped a monocle This is why I don't bother with estimates any more - not because I think it's impossible, or even necessarily too hard, but because I've observed (consistently over a 30 year career) that it's pointless. Even if you could estimate with perfect precision exactly how long a software task was going to take, they would just push back, say, "that's too long" and argue with you until you told them what…

Early in my career I had this. I was given a task and a deadline, and told to prepare a plan. I estimated the plan, and it came out to longer than the deadline. I presented this, only to be told "but that's longer than the deadline! go fix it!". So I shortened all the estimates and it fit the deadline. When I presented this I was shouted at for shortening all the estimates, and told to go back and do it properly. Aro…

Unfortunate; most of us have had experienced such situations separately, it sucks when they come together in a "rock and hard place" situation.

Good managers / business leads/ execs / champions CAN be reasoned with, as long as you find common language, think and understand their priorities, provide alternatives that meet their underlying goals (all of which frequently falls on the presenters). E.g. in your situation, it may be that unspoken expectation was to cut scope or increase resource contour or find another way to meet deadline rather than just changing estimates; or something completely different.

Occasionally though, you're as you say stuck between other people's indecipherable politics. I find in such situations, I'm most comfortable speaking the most honest truth and working hard, openly and explicitly, to understand/ask/bring to surface everybody's actual critical goals.

Re: Planning and estimating large-scale software projects

#33

Post by some_chap » Wed, Jul 21, 2021, 5:20 PM UTC

kalleth wrote: post #19

antondd wrote: post #14

This brings back memories from the days of my early career (an ex-PM survivor here). I would be curious to see some data, even anecdotal, on the success of this approach. Here's some interesting statistics from the industry (not specific to software, but you can extrapolate): http://apepm.co.uk/project-management-statistics/ In my view, traditional software project management is ineffective. I would put it somewhere…

Insightful, thank you! The entire project management industry doesn't have that great a "hit rate" -- consider the budget overruns for the last few Olympics, or for Crossrail. I'm just not sure why software projects are "special" -- if you can avoid it being a project and instead make it ongoing OpEx like, for example, GDS managed for the UK in 2016, then great, you've sidestepped that, but until the entire PM indust…

I'd say that software is "special" because it's ephemeral, meaning there's incredibly few limitations on the possibilities (or changes to requirements mid-project) when compared to projects involving physical items. It /can/ be managed like a physical engineering project, but the cost and time ramp up so severely that it's not practical for most situations.

Re: Planning and estimating large-scale software projects

#34

Post by ragebol » Wed, Jul 21, 2021, 5:21 PM UTC

ColinHayhurst wrote: post #10

> Estimates are one of the hardest parts of software development. And also fundamental. When I was directly estimating big software projects the key, for me, was to trust developers recommendations but apply a different multiplier for each developer. Multipliers ranged from x1 to x3. Those rare devs with x1 were, of course, a blessing. And those with x3 were not necessarily bad; they were often the ones working on th…

How much learning time did you typically need to arrive at that multiplier?

Re: Planning and estimating large-scale software projects

#35

Post by ngrilly » Wed, Jul 21, 2021, 5:21 PM UTC

marcosdumay wrote: post #31

ngrilly wrote: post #22

> It also tells us how many team-weeks this fictional, idealised project would require [...] by adding all the estimates together. I would be wary with just "adding all the estimates together". That's because we tend to estimate the median or the mode of the task duration, and not the average. Means can be added together, but not medians.

> Means can be added together Is the error distribution of task size estimations normally distributed? Because I do really expect it to have a fat tail, and if it does, you can't add means either.

I think most of us in software engineering assume the probability distribution has a fat tail. I've seen some authors name this the "blowup factor". For instance, your most likely estimation is 10 days, best case is 5 days, and worst case is 30 days. I think adding means is still meaningful (see central limit theorem and law of large numbers).

Re: Planning and estimating large-scale software projects

#36

Post by LegitShady » Wed, Jul 21, 2021, 5:26 PM UTC

ColinHayhurst wrote: post #10

> Estimates are one of the hardest parts of software development. And also fundamental. When I was directly estimating big software projects the key, for me, was to trust developers recommendations but apply a different multiplier for each developer. Multipliers ranged from x1 to x3. Those rare devs with x1 were, of course, a blessing. And those with x3 were not necessarily bad; they were often the ones working on th…

The multiplier was the same way I dealt with estimating time budget for homework in university. I would estimate the amount of time I thought it should take and multiply by 3 and it would usually take between 2-3x at the end.

It's a little harder when the work is more nebulous and I don't have to do it for others but it's all based on personal estimations of productivity as well as understanding of the problem. It's not easy to do.

Re: Planning and estimating large-scale software projects

#37

Post by marcosdumay » Wed, Jul 21, 2021, 5:30 PM UTC

ngrilly wrote: post #35

marcosdumay wrote: post #31

Earlier quoted context omitted.

> Means can be added together Is the error distribution of task size estimations normally distributed? Because I do really expect it to have a fat tail, and if it does, you can't add means either.

I think most of us in software engineering assume the probability distribution has a fat tail. I've seen some authors name this the "blowup factor". For instance, your most likely estimation is 10 days, best case is 5 days, and worst case is 30 days. I think adding means is still meaningful (see central limit theorem and law of large numbers).

It's exactly the central limit theorem that breaks for fat tailed distribution.

Some fat tail distributions also break the law of large numbers, but I don't think task size estimation is this flawed.

Re: Planning and estimating large-scale software projects

#38

Post by ColinHayhurst » Wed, Jul 21, 2021, 5:31 PM UTC

ragebol wrote: post #34

ColinHayhurst wrote: post #10

> Estimates are one of the hardest parts of software development. And also fundamental. When I was directly estimating big software projects the key, for me, was to trust developers recommendations but apply a different multiplier for each developer. Multipliers ranged from x1 to x3. Those rare devs with x1 were, of course, a blessing. And those with x3 were not necessarily bad; they were often the ones working on th…

How much learning time did you typically need to arrive at that multiplier?

At the end of two completed projects from each new starter

Re: Planning and estimating large-scale software projects

#39

Post by crazy1van » Wed, Jul 21, 2021, 5:37 PM UTC

henning wrote: post #25

Bullshit. You can make guesses about the future, but since that is going to inevitably change, it's a guess and can never be anything but a guess. At most companies, the scope is going to be radically expanded and looking too far in the future is a complete waste of time. Other people in other fields are held accountable for deadlines because their work does not completely change and is not severely under-specified.…

> it's a guess and can never be anything but a guess

Of course it's a guess. The question is how to make more accurate guesses.

Re: Planning and estimating large-scale software projects

#40

Post by marcus_holmes » Wed, Jul 21, 2021, 5:40 PM UTC

kalleth wrote: post #29

marcus_holmes wrote: post #28

Earlier quoted context omitted.

Early in my career I had this. I was given a task and a deadline, and told to prepare a plan. I estimated the plan, and it came out to longer than the deadline. I presented this, only to be told "but that's longer than the deadline! go fix it!". So I shortened all the estimates and it fit the deadline. When I presented this I was shouted at for shortening all the estimates, and told to go back and do it properly. Aro…

That's really tough, and I'm sorry you had to deal with it. I was lucky in that I was dealing (in both cases where I've run similar flows to this) with above-board exec teams who wanted the best quality information I could give them - even assuming that estimates are just assumptions - even if it meant having some tough conversations about scope or headcount.

Like I said, it was early in my career. I now know how to handle this - ask more questions and work out what the real objective is. Also refuse to let people shout at me ;)