Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software effort estimation is mostly fake research

shape-of-code.coding-guidelines.com

Post reply on HN
Print view View original

91–100 of 318 posts

Re: Software effort estimation is mostly fake research

#91

Post by vincentmarle »

I've been using the Rumsfeld Matrix to classify software estimations into 4 categories:

Known knowns: familiar tasks that can be reliably estimated from past experience. You can improve these estimates by better knowledge sharing (internal wiki, adding comments).

Unknown knowns: tasks that can be increasingly better estimated the more time you spend on estimating (for example creating Draft PRs with pseudo code).

Known unknowns: tasks that haven’t been done before, so estimations need a decent buffer (30-50%) to account for research and potential blockers. You can improve these estimates by benchmarking your previous efforts combined with the team's skill levels (aka sprint story point velocity).

Unknown unknowns: the unforeseen blockers that come out of nowhere, can't really be estimated, and can really disrupt a project's schedule. Improving these estimates is really hard. The key to improving these is by improving team/company communication and building agile feedback loops so you can identify these issues early and reprioritize as needed.

Re: Software effort estimation is mostly fake research

#92

Post by ghaff »

Jtsummers wrote: post #72
ghaff wrote: post #57

Earlier quoted context omitted.

Back when I was a product manager, there was an engineering manager who would drive me crazy. He had this idea of a 90% schedule, by which he meant a 90% chance of hitting if everything went as planned. Everything never went as planned.

He probably read Goldratt's follow-on to The Goal , Critical Chain . Critical Chain Project Management is the specific term. Goldratt tried to sell software to companies that would help them make schedules like that, but a large component (often ignored) was collecting historic data, and running models. Most companies might do one of those, but rarely both, and of course models with only speculative numbers are absol…

I think this was a little before that (mid-90s) but maybe something related.

Re: Software effort estimation is mostly fake research

#93

Post by djoldman »

>Those estimation datasets that were flogged to death in the 1990s using non-machine learning techniques, e.g., regression.

>...non-machine learning techniques, e.g., regression.

Is this where we are now? The connotation of "machine learning" doesn't include regression? Wow.

Re: Software effort estimation is mostly fake research

#94

Post by RicoElectrico »

ChrisMarshallNY wrote: post #34

I find this amusing. Know how much a Honda Accord costs? About 25 Grand. Know how much a Mercedes S450 costs? About three times as much. They are both great cars, that will be rewarding to own. The Mercedes doesn't have 3 times more parts, but it probably took four times longer to make, and they paid the folks that make it, a lot more than the Honda. It's actually, probably better "bang for the buck," although it won…

We should not conflate quality with value. [1]

[1] https://moznainaczej.com.pl/Download/Teal%20Doctrine/A.Blikl... (13.10 Quality and value)

Re: Software effort estimation is mostly fake research

#95

Post by winrid »

ChrisMarshallNY wrote: post #34

I find this amusing. Know how much a Honda Accord costs? About 25 Grand. Know how much a Mercedes S450 costs? About three times as much. They are both great cars, that will be rewarding to own. The Mercedes doesn't have 3 times more parts, but it probably took four times longer to make, and they paid the folks that make it, a lot more than the Honda. It's actually, probably better "bang for the buck," although it won…

High quality != high feature count. You are conflating the two with your anology.

You don't want to daily drive a 30 year old performance oriented Mercedes.

An Accord however, most generations can hit 300k miles easily.

The Mercedes is more expensive because they put more investement into refinement and luxury. Make the doors feel right. Ensure the torque curve is flat and starts at a low RPM, usually using turbo chargers that will fail by 200k miles. Lots of carefully placed sound deadening.

This isn't higher quality, it's extra features.

Re: Software effort estimation is mostly fake research

#96

Post by impy »

curiousllama wrote: post #38
Aldipower wrote: post #4

I am 20 years in development business now. This simple rule of thumb works for me and the team: (Your honest and concise estimation) * 3 There are just to many unknowns you cannot foresee. Software development is complex.

I've been hearing this rule for years now, and I think the coefficient is increasing. It started at 1.5x, now it's at 3x... Is this just me?

I'd say this is Parkinson's Law at play

Re: Software effort estimation is mostly fake research

#97

Post by KineticLensman »

csours wrote: post #14
1337shadow wrote: post #9

Earlier quoted context omitted.

Make a complete list of things to develop in a spreadsheet, "complete" means every single item the customer wants to see in the product, not only every single button but also every single label, that should be definable by reading the project specs or mockups. I think "forgetting things" is the first big mistake leading to under estimations. Add an estimate that you multiply by three in front of each, ie. if the dev…

> "complete" means every single item the customer wants to see in the product, Ah, but the customer does not know everything they want, due to the fractal nature of reality. The closer you get to the end product, the more detail is resolved, and more work is added.

Another way of looking at this is that (unless there is a complete disaster) as you get closer to the end the uncertainty in the estimate decreases. When you get to the end, you know precisely how long it took.

Re: Software effort estimation is mostly fake research

#98

Post by snarf21 »

didibus wrote: post #82

The issue with estimates are expectations. While nobody acknowledges it, you're not actually asked for an estimate, you're being asked for a quote. The difference is when you're asked for a quote, you're asked how much you will be charging, with the expectations that you'll be willing to eat into your own margins to give a lower quote. That's why it's a negotiation, where you negotiate how much extra effort, time and…

The issue is that you are being asked to estimate something that has never been done before. Even houses always go over time and money and that is fairly straight forward.

These days, I only give estimates in terms of units but without numbers. Hours, days, weeks, months, quarters or years. Some relatively small number of those units. If you want a quote it will take an extra 1/4 of the estimate worth of time for an exact timeline. I really wish we would treat sales people the same way. "How much money is this contract for? What date will it be signed?"

Re: Software effort estimation is mostly fake research

#100

Post by BowBun »

It's unfortunate that this HN thread has been reduced to the generic discussion about software estimates when the article is specifically talking about research done on the topic of software estimates.

According to the article, proper research remains a struggle due to outdated datasets from before modern agile methodologies, and that the modern datasets from industry are hard if not impossible to gather.

If industry is truly interested in improving software development and estimation, their data should be anonymized and made available to researchers for analysis.

Post reply on HN