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

Re: Planning and estimating large-scale software projects

#71

Post by marcosdumay » Wed, Jul 21, 2021, 7:31 PM UTC

majormajor wrote: post #64

commandlinefan wrote: post #57

Earlier quoted context omitted.

> I won’t be mad about a long estimate So... my experience with this mindset is that you won't be mad , but you'll just say "that's too long/expensive" and cancel the project entirely. Then the same project will come up again in two months with different wording, again and again, until I give you the estimate you think you can afford. And then the thing will end up taking longer than the original "too expensive" esti…

I've seen this, but I don't think it was a problem or a bad thing. Let's say the project was first proposed in January 2021. Got estimated as taking a year. Didn't get scheduled, since that was seen as too long, and there was other stuff people wanted done in 2021. It's pitched again in June 2021. Same story. Come Feburary 2022, it's pitched again. Now it's estimated as 15 months - there's more to do since more code…

Hum... The way to GP is written looks more like the scenario that the dev manager/PM/whatever comes to the team with the problem and gets the 1 year estimate, says "it's too expensive" and closes the project. A few weeks later, somebody states the problem again and pushes the manager to get another estimate, that is too large, so the project is closed.

Repeat that until the problem gets a singularly misleading wording, or some key person is away, and the project gets a 6 weeks estimation. It will take 19 months anyway, because nothing changed, but for 17 of those you will be late.

(Anyway, I have never seen a problem statement to be well defined enough for this to be the problem.)

Re: Planning and estimating large-scale software projects

#72

Post by heresie-dabord » Wed, Jul 21, 2021, 7:33 PM UTC

28304283409234 wrote: post #24

I've started estimations by their true name: Assumptions.

For those who are new to software development, the following terminology may prove helpful:

Software Project Estimumption (or Assumptimation, the professional community is split)

Software Requirements GatherWhims

Software Requirements Analysthetics

Unit Test Coveroverage

Re: Planning and estimating large-scale software projects

#73

Post by jdlshore » Wed, Jul 21, 2021, 7:33 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.

There’s a variety of analyses out there and they very consistently show a log-normal distribution for release predictions. I’ve analyzed Star Citizen’s publicly available data and found the same for their task estimates. It’s very reliable.

You do see truncated log-normals, though, when the estimates are padded.

Re: Planning and estimating large-scale software projects

#74

Post by majormajor » Wed, Jul 21, 2021, 7:38 PM UTC

marcosdumay wrote: post #71

majormajor wrote: post #64

Earlier quoted context omitted.

I've seen this, but I don't think it was a problem or a bad thing. Let's say the project was first proposed in January 2021. Got estimated as taking a year. Didn't get scheduled, since that was seen as too long, and there was other stuff people wanted done in 2021. It's pitched again in June 2021. Same story. Come Feburary 2022, it's pitched again. Now it's estimated as 15 months - there's more to do since more code…

Hum... The way to GP is written looks more like the scenario that the dev manager/PM/whatever comes to the team with the problem and gets the 1 year estimate, says "it's too expensive" and closes the project. A few weeks later, somebody states the problem again and pushes the manager to get another estimate, that is too large, so the project is closed. Repeat that until the problem gets a singularly misleading wordin…

> Repeat that until the problem gets a singularly misleading wording, or some key person is away, and the project gets a 6 weeks estimation.

At that point we're definitely at a point of "severe company process problems" and the method outlined in the original article probably isn't feasible - I can't really imagine that manager accepting the time required to create a GOOD estimate - but I've definitely seen it work properly at some of my jobs.

Re: Planning and estimating large-scale software projects

#75

Post by majormajor » Wed, Jul 21, 2021, 7:40 PM UTC

commandlinefan wrote: post #68

stingraycharles wrote: post #62

Earlier quoted context omitted.

I think this attitude is too fatalistic. A good approach would be to see if there’s some way to break up the feature in smaller pieces, into smaller milestones, etc. If you have a manager that is unable to deal with this kind of stuff, then your problem is the manager, not the estimates. Estimates are extremely useful, and you’re doing yourself a disfavor if you think that they are never meaningful.

If I was surrounded by people who could put together accurate software estimates that made upper management happy, and I was the only one who was always got it wrong, I'd hang up my hat and see if I could get a job selling life insurance. Hell, if 10% of my peers could put together accurate software estimates that made upper management happy, I'd lobby to have them elevated to senior positions and spend all my time b…

> But they don't. Nobody does. They don't just get the timelines wrong, they get the tasks and milestones wrong - which makes sense, because the people asking for the estimates don't actually know what the goals are, usually even after the software is delivered.

I definitely agree that the people asking don't actually know what the goals are. They usually have a very fuzzy picture there.

But I've always found the estimation and planning process to be hugely valuable for revealing the questions that reveal to THEM that they don't know all those requirements yet. And then we have a discussion about them, and we get better specs as a result, and then go on from there... which is way better than when we don't discover those gaps until we are writing the code for it!

Re: Planning and estimating large-scale software projects

#76

Post by dpweb » Wed, Jul 21, 2021, 7:42 PM UTC

I found it really fluctuates based on the team members. We definitely had 3x 4x differences in productivity between the worst and best on the team. Our estimates had to be good as it determined the size of the sales deal. Most everyone on the team was there for years, so we knew each other well. We could give a solid estimate but with a new team member is more challenging.

Re: Planning and estimating large-scale software projects

#77

Post by killjoywashere » Wed, Jul 21, 2021, 7:45 PM UTC

msluyter wrote: post #52

killjoywashere wrote: post #48

Earlier quoted context omitted.

A Jira plug-in to use some sort of Bayesian system to adjust developer priors at the task and sprint level. That would be amazing.

Yeah I've always felt like the missing part of the loop (in the context of pointing stories) is looking at point estimates and then tracking how accurate they were, _by developer_. E.g., I throw 2 points, but it turns out the story takes something along the lines of 13 points, then my estimation was pretty low and my personal "estimation multiplier" is increased. Subsequently, actual point estimations could take the…

Just look at completion rates within sprint. How many points did they commit to, how many did they finish. 2 weeks is a fine unit of time.

Re: Planning and estimating large-scale software projects

#78

Post by tel » Wed, Jul 21, 2021, 8:08 PM UTC

killjoywashere wrote: post #48

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…

A Jira plug-in to use some sort of Bayesian system to adjust developer priors at the task and sprint level. That would be amazing.

FogBugz used to do something of that nature. I never used it, so I'm not sure how well it worked out ultimately.

Re: Planning and estimating large-scale software projects

#79

Post by mumblemumble » Wed, Jul 21, 2021, 8:14 PM UTC

> you should expect to be held accountable if your estimates are too far off the mark because you failed to do your due diligence when coming up with them.

In a perfect world, I agree.

In the real world, which has a remarkable knack for failing to live up to expectations, what I find is that companies are rarely willing to allow the development team adequate time to do their due diligence. Answers, in and of themselves, are cheap. I can give you those all day. If you want to be able to hold me accountable for their accuracy, though, then you need to be looking at my correct answer rate sheet.

For me, the magic of #noestimates is the magic of open, honest cynicism. If my realistic options are silence and blowing smoke up my boss's ass, I'd really prefer it if they would allow me to choose silence. That way we can both keep our dignity.

Re: Planning and estimating large-scale software projects

#80

Post by lifeisstillgood » Wed, Jul 21, 2021, 8:15 PM UTC

- Projects only become official and tracked once someone has hacked together enough of a prototype to prove it works.

- at this point all project management is pretending it takes 100 managers to land something one girl / guy got flying.

- stop project managing, stop estimating, and just start treating companies as VC firms. Hire good devs, make them care about your mission, invest in those that take off. Don't take the control away from the original devs