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

Software effort estimation is mostly fake research (2021)

shape-of-code.com

Post reply on HN
Print view View original

171–180 of 212 posts

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

#171

Post by smileysteve »

rswail wrote: post #157
smileysteve wrote: post #155

Earlier quoted context omitted.

Re: China train example. Now do a California rail from San Francisco to LA. Answer, you can't. Earthquakes, Land Acquisitions. Src https://www.washingtonexaminer.com/opinion/california-imagin...

Run an elevated train along I-5? There are no engineering solutions to earthquakes? Railways can be repaired. Land Acquisition is a government and regulatory issue, not engineering.

This wasn't a hypothetical, but based on a delayed project https://www.washingtonexaminer.com/opinion/california-imagin...

Government and regulatory issues apply to engineering whether it's software engineering, building engineering, or train engineering.

(In software, intra company estimates can easily be blocked with political "do it with only the current existing infrastructure or conventions" or my favorite, "now prove it in a test environment, but I'll give you 0 resources for a test environment", and government / business related - ie the cost of security breach, GDPR compliance, payment compliance, Twitter,Google Maps, or reddit making api access and pricing changes)

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

#172

Post by AnimalMuppet »

MrBuddyCasino wrote: post #136
nprateem wrote: post #47

My conclusion is there are 2 kinds of engineer: good ones and shit ones. Good ones just need to be told what to do and be left to get on with it. They value autonomy, and any attempt to micromanage them with agile bullshit drastically demotivates them. Shit ones are shit. They need a good one to help them get through their tickets, by asking what's taking so long and showing them better ways of approaching the proble…

I wish I could spend karma to upvote this more.

That would be a really interesting HN feature. You can upvote once, and it's free. But if you really feel strongly, you can upvote more, but each additional upvote costs you a karma point.

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

#173

Post by bkirkby »

danielvaughn wrote: post #23

I feel like the core problem here is one that can never be resolved, because it's the result of two valid but opposing forces. On one hand you have business stakeholders, who can see the business reality - money doesn't grow on trees and runways are very real and scary, so without deadlines companies fundamentally cannot function. On the other hand you have engineers, who either explicitly or implicitly understand th…

"money doesn't grow on trees and runways are very real and scary, so without deadlines companies fundamentally cannot function."

Runways being real doesn't mean you need deadlines. Deadlines are useful to motivate the unmotivated.

The better path to dealing with shrinking runways is early and continuous delivery of valuable software. This is facilitated by making sure the team is aligned and onboard with the solution (for motivation) then giving them the environment, support, and trust to get the job done.

This is further enhanced by self-organized teams since the best architectures, requirements, and designs emerge from self-organizing teams.

With that emergence, the team will deliver valuable and working software at regular intervals (measured by weeks or months at most, preferring the short timescale) and the stakeholders will determine when that valuable software is valuable enough for customers to pay for.

This early and continuous delivery is the primary measure of progress. It also facilitates a welcoming of changes to the requirements at any stage (as the focus is delivering value, not getting a roadmap done).

Roadmaps and deadlines will often get in the way of this system of efficiency in software delivery precisely because the estimation game gives team permission to use all the time negotiated in the estimation, which is already padded enough to ensure an "under promise and over delivery."

All of this is taken straight from the agile manifesto (which is over twenty years old now): https://agilemanifesto.org/principles.html

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

#176

Post by AnimalMuppet »

I remember when I was a kid, being on a family vacation, driving up I-15 in Idaho. At one particular place we topped over a hill, and the road was straight from there to an overpass across the road way down in the distance. I wondered how my dad could aim so well that he'd go under that overpass all the way down there.

Now I know that he didn't aim that carefully. Instead, he kept steering.

Estimates are estimates. Sure, try to get them approximately right. (By the way, you can't get better if you don't close the loop. Look at estimates vs. reality on your own estimates in the past.) But even good estimates will only be somewhat close to right. You need management that will steer all along the road from estimate to reality. You also have to give them the feedback information so that they can steer.

Your estimates shouldn't be off by a factor of 10. "Off by a factor of two" isn't great, but it's not horrible - though they shouldn't always be off by a factor of two in the same direction. If management understands that that's what they're getting, and they know how to work with that, fine. If they think they're getting much more precision than that, that's a management problem.

(This is an oversimplification. For some kinds of work, you or your team or company has done that kind of work many times before, and you can easily be more accurate than a factor of two. Other times you need a research project just to identify the parts involved, then another research project to discover whether you can solve those parts, then yet another research project to be able to estimate how long those parts will take. Then you can give an estimate, and it still won't be a very precise one.)

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

#177

Post by mikeryan »

rswail wrote: post #153
mikeryan wrote: post #43

Earlier quoted context omitted.

Similar point. I’ve been running an agency for 14 years. All that time we’ve tracked hours for every project whether T&M or fixed bid. Now when a project comes in for bid I always estimate it based on experience but then validate it against one of 250 projects we’ve done that seems “similar” in scope. Since doing that we’ve only been off significantly when we misunderstood the original scope. Tracking hours is a pain…

> Tracking hours is a pain in the ass and we do it mostly in Jira tied to tasks but the data we get is invaluable. The important point here is to actually feed that information back to the people that originally did the estimates and also to the people that are (to them) "pointlessly" clicking on the "start work", "stop work" buttons on their JIRA tickets. Most of the time, this sort of timesheet stuff is fed to an a…

Yeah we mostly don’t do the start/stop thing with timers. For the most part we just have folks guesstimate the hours spent when the close or reassign a ticket. Hour or half hour precision is good enough.

We don’t hide hours and use them as a tool for raising flags as part of our weekly or bi-weekly reviews with team leads and part of our client reporting. If a lead sees someone spending too much time on a task it raises a flag on whether the task is unexpectedly large, impacting schedule and/or scope or if someone is potentially slacking off or having some other personal issues etc.

We are primarily remote and, like most agencies, will backfill sometimes with contractors. We’ve been hosed a few times with people sandbagging hours so making all this data public and reviewed has been a great way to hold everyone accountable.

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

#178

Post by rswail »

jillesvangurp wrote: post #97

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…

> Humans are bad at estimating stuff. Software engineers doubly so.

Where did you get that factor of 2 from? /s

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

#179

Post by ghotli »

beezlewax wrote: post #90
ghotli wrote: post #61

At least when I was younger I was so perplexed by the kind of co-workers that have apparently chosen the profession of working with estimates from other people but continually work without a "confidence level" associated with each estimate. ("two weeks") means such a different thing in reality from ("two weeks", "confidence of 50%"). It's a tuple, it's always been a tuple, it's just downright silly to accept an estim…

It doesn't get better with magic values like confidence levels either

You might imagine I disagree having written that flippant comment last night. On the contrary I've been on both sides at length over my career. While I find the tuple information somewhat useful (if I'm forced to provide semi-informed-guesses around timelines), I ultimately deep down agree with you wholeheartedly. The utility is moreso in having the conversation about why the confidence is low, which many methodologies have their own words and processes for.

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

#180

Post by regularfry »

constantcrying wrote: post #72
eftychis wrote: post #60

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…

Your first mistake was misunderstanding the relationship with management. Time estimations are bargaining, you ask for something and then get a counter offer from management, they don't care that the counter offer from them is delusional. The bargaining is the point, the less time you bargain for the more stressful the development can become. Don't estimate what it should take, estimate what it could take and bargain…

The correct response to that sort of bargaining attempt is "What are we dropping from the project scope?"
Post reply on HN