Live data from Hacker News

Software effort estimation is mostly fake research (2021)

shape-of-code.com

121–130 of 212 posts

Re: Software effort estimation is mostly fake research (2021)

#121
post #37

It's not fake research. It's actually quite an established science in the 24 years I've been doing it. Take your first guess, double it, double it again if the stakeholder is a poser, add 20% per developer less experience than you, subtract 10% for the features you're going to essentially copy paste, add 15% for sick leave (browsing HN) and then double it for every question you have that are unresolved and divide it…

The real problem is not with estimation but with the management denial. I was asked to estimate a project I owned as a “green” lad. I offered 6 months with a real detailed plan and up to a year with some extras. Based on past rates we had etc. I even did some statistical modeling. They disagreed. They decided to alter the approach, that the principal engineer had suggested and “it would take 2-3 months.” Two years la…

>>>. The real problem is not with estimation but with the management denial.

^^ This is the truth. All estimation processes in any company are just ceremony. Management already has a deadline fixed. They will make you agree to their deadlines, even though whatever process stipulated by them says otherwise.

Re: Software effort estimation is mostly fake research (2021)

#122

I spent 6 months on a feature that I thought would require 2 lines of code and less than an hour to test and ship. It took 1 month dissecting spaghetti to conclude the task was impossible without a hughe rewrite. 5 months later, the feature was a 2 line change, that could be tested and shipped in an hour.

Thats true. For system complex enough you will spend more time learning system than modifying it. Thats why all developers love to write new code and mostly hate to suport existing, working, legacy code.

Re: Software effort estimation is mostly fake research (2021)

#123
post #45

Earlier quoted context omitted.

> Can you make a step plan for some deliverable? No? Then, sorry, it's not that planning is not possible, it is that you are simply not experienced enough. Perhaps you work in a simple domain? This would be infeasible at my current job, and that's including the best-in-the-industry people with 20 years experience.

What’s your domain? Are you working on a mission critical system? Are you trying to solve an algorithmic problem that is novel enough to warrant a publication after you solve it? If not, I doubt estimating is innately infeasible. If your best-in-industry people can’t do it it’s because they probably haven’t valued it enough in their career to develop the particular skill set.

I have some experience with healthcare software and the core of it is pretty simple. The 2 biggest sources of unknowns however are quirks of the existing system and edge cases in human processes. Neither can be accurately estimated for because complex systems are never documented in enough detail and even humans who have been using them for decades overlook and misremember things.

I’m sure this is the case in any complex enough business system as well.

Re: Software effort estimation is mostly fake research (2021)

#124

A bad estimate is better than no estimates at all. There are plenty of empirical studies that prove that. Some computer scientists have a hard time dealing with non mathematical proofs. They have a huge blind spot for things like empirical case studies, qualitative studies, etc. Those are tools that people in other fields use when mathematical models fall short. There are not a lot of useful mathematical models you c…

> But even a bad estimate gives you some handle on how easy or hard something is to do Can’t agree with this at all. A bad estimate is by definition bad. How does it give you a handle on anything if it’s unreliable? It’s like saying bad medicine is better than no medicine. And when you talk about breaking an estimating problem into smaller estimates, you’re now firmly in the domain of actually doing the work. An econ…

That's the problem. You have an opinion but no empirical evidence and you think your opinion is pretty good. There's plenty of material out there that is a bit more well reasoned that disagrees with your opinion. For example Don Reinertsen's books.

Most Agile estimates are pretty bad. But that's OK because it's still better than just winging it. One of the realities of working with real companies is that they have things like dead lines. Programmers don't like them. The don't believe in them. They are bad at delivering stuff on them. But they still exist. The reason agile/lean/scrum/etc. exist is to beat some sense into programmers completely and utterly failing to deliver anything on a predictable schedule. Bad estimates are the foundation of these processes. Where bad is better than no estimates and the rest of the process is about mitigating the consequences of the estimates being low quality.

Re: Software effort estimation is mostly fake research (2021)

#125

Earlier quoted context omitted.

everyone works on stuff that's more complicated than it looks from the outside, and many other fields are able to estimate the amount of work it takes to do something. why cant software? example: in 2006 china formalized plans to build a totally new high speed train system that spans the entire country by 2020, a totally new level of scale that had never been done before. and the plan worked out even a bit ahead of s…

We’ve been building railways for what, 200 years now? Heck the old ones were built by hand .

how to tell me you have no idea what youre talking about without saying it directly

Re: Software effort estimation is mostly fake research (2021)

#126

A bad estimate is better than no estimates at all. There are plenty of empirical studies that prove that. Some computer scientists have a hard time dealing with non mathematical proofs. They have a huge blind spot for things like empirical case studies, qualitative studies, etc. Those are tools that people in other fields use when mathematical models fall short. There are not a lot of useful mathematical models you c…

A bad estimate gives you a handle on how easy or hard your engineers think that something is. Experience shows that this has little correlation with how easy or hard something really is.

That's a good example of a qualitative statement that would be a lot more credible with a lot of empirical evidence backing that up. "Experience shows" is not enough here. Raises more questions than that it solves anything here really.

Basically uncertainty is the key concept here. And cost, complexity, and time estimates are ways to get a grip on such uncertainty. Unlike software engineers, economists and sociologists are used to reasoning about and modeling uncertain situations. Going all hand wavy and winging it is typically not what they advertise.

Re: Software effort estimation is mostly fake research (2021)

#127
post #121

Earlier quoted context omitted.

The real problem is not with estimation but with the management denial. I was asked to estimate a project I owned as a “green” lad. I offered 6 months with a real detailed plan and up to a year with some extras. Based on past rates we had etc. I even did some statistical modeling. They disagreed. They decided to alter the approach, that the principal engineer had suggested and “it would take 2-3 months.” Two years la…

>>>. The real problem is not with estimation but with the management denial. ^^ This is the truth. All estimation processes in any company are just ceremony. Management already has a deadline fixed. They will make you agree to their deadlines, even though whatever process stipulated by them says otherwise.

Not EVERY company. Just the ones that don't understand how estimation works... and unfortunately in software, that's still a very very common case. In more established kinds of engineering it works differently... which gives me hope that eventually our industry will understand too.

Re: Software effort estimation is mostly fake research (2021)

#128

Earlier quoted context omitted.

> But even a bad estimate gives you some handle on how easy or hard something is to do Can’t agree with this at all. A bad estimate is by definition bad. How does it give you a handle on anything if it’s unreliable? It’s like saying bad medicine is better than no medicine. And when you talk about breaking an estimating problem into smaller estimates, you’re now firmly in the domain of actually doing the work. An econ…

That's the problem. You have an opinion but no empirical evidence and you think your opinion is pretty good. There's plenty of material out there that is a bit more well reasoned that disagrees with your opinion. For example Don Reinertsen's books. Most Agile estimates are pretty bad. But that's OK because it's still better than just winging it. One of the realities of working with real companies is that they have th…

[deleted]

Re: Software effort estimation is mostly fake research (2021)

#129
post #69

Earlier quoted context omitted.

> money doesn't grow on trees and runways are very real and scary, so without deadlines companies fundamentally cannot function. That's a non-sequitur. there are plenty of ways to run a project under a budget that don't involve deadlines.

Interesting, though not sure I follow. My reasoning is that the ultimate deadline is the “we run out of money and go out of business” point, from which all other points follow. So a project may be organized differently, but under the hood it’s all the same - get more money before you lose all the money.

Say you have a half-sized team in order for the remaining people to get twice as much time. People working on the project will, on average, be more familiar with the problem. That's not a frequent answer, since most companies are more time-sensitive than budget-sensitive. But that's a good illustration of how budget and timeline are separate things.

That being said, my initial message wasn't about that, but about the idea that plenty of organizational methods abandon tight deadlines in favor of early feedback.

That usually works better when power is decentralized, since the higher you report to, the less people have time to actually look at what you produce (and therefore, the more they rely on low-involvement management methods such as setting deadlines). On the other hand, the more decision power is decentralized to the people actually using the software, the more early feedback will make setting deadlines redundant.

Re: Software effort estimation is mostly fake research (2021)

#130
What mostly worked for me was two simple things: splitting the big tasks and constantly evaluating evaluations. With more smaller evaluations negative and positive errors anihilate each other. With adjusting the evaluations you can reach the a point where you don't have errors on only one side.

A very good book on software estimation is: https://www.amazon.com/Software-Estimation-Demystifying-Deve...

Post reply on HN