Live data from Hacker News

Software effort estimation is mostly fake research

shape-of-code.coding-guidelines.com

211–220 of 318 posts

Re: Software effort estimation is mostly fake research

#211
post #100

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…

What data would be useful here? There are so many confounding factors.

Well, isn’t that the kind of thing researchers ought to be researching?

Re: Software effort estimation is mostly fake research

#213
post #98

Earlier quoted context omitted.

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…

> These days, I only give estimates in terms of units but without numbers. Hours, days, weeks, months, quarters or years. Then you must be either an independent contractor or have some magical source of job security. I couldn't get away with this kind of estimate.

Probably more to do with personality mix than circumstance. I've had bosses where I could say things like that and get away with it. I've also had bosses where if I said something like that, I'd be packing up my desk.

Re: Software effort estimation is mostly fake research

#214
post #76

Earlier quoted context omitted.

Apple executes massive feature releases on a yearly waterfall-like schedule across hundreds of teams. It requires honesty, transparency, strong leadership (ruthless prioritization), strong cross-team goodwill, strong cross-team collaboration as well as a solid body of experienced top-tier engineers. Other than that there's no magic. While there are teams within apple that does scrum/agile, none of the core OS/framewo…

Have you noticed their declining OS release quality in recent years? I have, and I now wait 6 months to upgrade. The triangle is real[1]. Something's gotta give when a deadline can't move, and as we know from Brooks, software development speed doesn't increase linearly with more people. So it's primarily quality or scope that must suffer to hit a software deadline. [1] - https://en.wikipedia.org/wiki/Project_manageme…

Honestly, Apple's decline traces back to losing Steve Jobs. The strategic changes were immediate, (and aimed at shorter term gains, things that people besides Jobs thought were being left on the table) the effects just took a long time to really add up to something meaningful. IMO, they never really recovered, they just are massive and have a HELL of a lot of momentum. It takes time to undermine that all even if you do everything wrong. They definitely are still doing some things right, but IMO, the type of thing you are complaining about is a leadership issue.

Re: Software effort estimation is mostly fake research

#215

Earlier quoted context omitted.

> And I’ve also seen wise use of estimation but that is rarer I've got a question for you here, what is a wise use of estimation? What problems are estimates the ideal solution for? In the context of software development? I can think of only two: planning headcount and priorities (aka planning the order in which you do things). When you focus on those problems, you realize there's no need for an accurate estimate. Al…

To get a rough idea of what work can be done in the next X weeks, so that the business can forecast. The wisdom comes in knowing things can change and it's just an estimate. The process of estimating is quite good as it requires finding out a lot more about how you will solve something, and planning things in advance.

> so that the business can forecast

Forecast to what purpose? What is the business actually trying to achieve for which they believe, maybe wrongly, they need accurate software estimates?

Re: Software effort estimation is mostly fake research

#216

Earlier quoted context omitted.

Yes exactly! When you ask someone for their estimate, you're getting a quote from them. When you actually want to predict the length of time something will take, you rely on historical data and create a projected forecast. It never involves asking somebody for their best guess. That's how every single "other thing" we predict is handled, so why is software done differently. Actually, I've seen some of these ideas bei…

Didn't Joel Spolsky implement it all the way back in the stone age... er, 2007[0]? The idea is old. The problem is, in many software companies, none of the tasks look alike. So your past data is going to be somewhat dirty, particularly at team level. Perhaps as an individual, intimately familiar with the problems you encounter, being able to introspect your own thought process - perhaps you or me, we could learn to e…

> The problem is, in many software companies, none of the tasks look alike. So your past data is going to be somewhat dirty, particularly at team level

Tasks don't really give you anything though. I think if it was measured in terms of features, that would work a lot better.

And with a Monte Carlo simulation, you get to know the time it would take you to complete any random feature on any random period. So maybe you can't perfectly predict that next feature, but in the year, on the average, your predictions should tend towards good accuracy.

And you could take it further, machine learn the feature request to the time it took. And then run the ML inference on any new feature request. Maybe let devs add some labels, it's not exactly estimating, but they could mention if say they think something is "complex", "ambiguous", "straightforward", etc.

I'm sure there'd be ways to do it.

Re: Software effort estimation is mostly fake research

#217
post #76

Earlier quoted context omitted.

Have you noticed their declining OS release quality in recent years? I have, and I now wait 6 months to upgrade. The triangle is real[1]. Something's gotta give when a deadline can't move, and as we know from Brooks, software development speed doesn't increase linearly with more people. So it's primarily quality or scope that must suffer to hit a software deadline. [1] - https://en.wikipedia.org/wiki/Project_manageme…

People have been saying that since OS X first came out, and OS 9 was so buggy it had a famous cute bomb icon for when it crashed.

Yeah, first few OS X releases were famously buggy as they were figuring this UNIX stuff and the OS 9 compatibility, but they stabilized about 10.4 Tiger.

Honestly the OS X itself (uhhh macOS now) is still fine, even with Big Sur and its weird iOS controls, however the other software is sometimes weird; but - let's say Numbers was never good and iWeb was always downright bad. And iTunes was bad in Jobs era and is still bad (as Music).

I however still kind of miss when native Cocoa apps were sort of good and not just ported iOS app via Catalyst or something. But whatever. I'm old I guess

Re: Software effort estimation is mostly fake research

#218
post #100

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…

I could imagine getting data from tools like Jira, but there is so little consistency on how data is entered and updated, I would have a hard time swallowing any conclusions from that data.

Re: Software effort estimation is mostly fake research

#220
post #98
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…

They do treat sales people that way. Sales is ruthlessly managed and expectations are very important, especially at a public company.
Post reply on HN