Software effort estimation is mostly fake research (2021) • Hacker News Board

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

#41

Post by IanCal » Fri, Jun 16, 2023, 3:13 AM UTC

qprofyeh wrote: post #34

wellpast wrote: post #32

I might be in a 1% of engineers that believe in estimation. 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. That's fine. There is something called skills, and you can go get them. Have you made a plan? Great, then is there is some task in your plan that you can't estimate? In rare cases that might be inherently t…

I tend to disagree. Estimate this more complex situation: Integrate vendor B’s API where you don’t have prior experience with vendor B’s product let alone their API, and where our system is built specifically around vendor A’s API and workflow. This requires backend and frontend (customer and admin UI) changes given that everything is tied to vendor A’s API currently.

Have you ever done this before? How long has it taken in the past?

What are the key first steps? Investigate the API and product right? How long has that taken when you've done it before? Your first deliverable is a plan of it's that unknown.

Now you've investigated you know more about what needs to be done. You can compare it to previous times you've done similar things and estimate how long it should take.

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

#42

Post by depereo » Fri, Jun 16, 2023, 3:13 AM UTC

skeeter2020 wrote: post #36

vletal wrote: post #24

Earlier quoted context omitted.

> We are building Sydney Opera Houses. Sorry, this made me laugh. I know there are software engineers which build clean and polished beautiful mega structures. I _aspire_ to that. Yet that is a niche market. In reality, most devs are making unique family Vilas at best. I wish I could ever say I feel like I contributed to an equivalent of 'Sydney Opera House'.

Most of us our building prefab housing, but the challenge is there's infinite ways to put the modules together, and unlike real housing no physics to reduce the problem set of possbilities.

Even the prefab stuff has unknown unknowns - but everyone skimps on the geotechnical assessments of the ground you're building on...

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

#43

Post by mikeryan » Fri, Jun 16, 2023, 3:21 AM UTC

awb wrote: post #6

Ran a successful digital agency for years. Estimation was mostly guesswork. There’s a theory that work expands to fill the time you give it and I found that to be largely true. Other agencies would quote 3 months for projects we’d complete in 6 weeks. Even then I was taking engineers 3 week estimates and doubling them for buffer. We didn’t do anything special other than commit individuals to a single project, or two…

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 in the ass and we do it mostly in Jira tied to tasks but the data we get is invaluable.

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

#44

Post by iopq » Fri, Jun 16, 2023, 3:28 AM UTC

klodolph wrote: post #30

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…

When the problem can never be resolved, you redefine the problem until you find a version of the problem with a good solution. So if the problem is that software is hard to estimate, which is hard, we redefine the problem to something like “I want to be able to ship something people want to buy, before we run out of money” or “I want to ship a game in time for Christmas” or “I want to reduce operating costs so we don…

> “I want to be able to ship something people want to buy, before we run out of money”

Buddy, if I knew the answer to the question "something people want to buy" I would be rich already

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

#45

Post by lostdog » Fri, Jun 16, 2023, 3:32 AM UTC

wellpast wrote: post #32

I might be in a 1% of engineers that believe in estimation. 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. That's fine. There is something called skills, and you can go get them. Have you made a plan? Great, then is there is some task in your plan that you can't estimate? In rare cases that might be inherently t…

> 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.

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

#46

Post by x86x87 » Fri, Jun 16, 2023, 3:32 AM UTC

ethbr0 wrote: post #29

x86x87 wrote: post #21

Earlier quoted context omitted.

Also, to get better estimates you need to sometimes do some [research] work. Without it ykur guesses are even wilder but with it you have to ack that you've spent time on it, evenif you never get to do the actual work.

I.e. spiral https://en.m.wikipedia.org/wiki/Spiral_model

TIL. Thanks for sharing this

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

#47

Post by nprateem » Fri, Jun 16, 2023, 3:34 AM UTC

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 problem. They need more handholding and don't yet find ticket-sizing a soul-sucking waste of time.

Shit ones might become good ones over time, or they might not.

The problem is that scrum masters are either former shit engineers or non- technical, so cling dearly to the belief they add some value to the process by acting like a parent (which only benefits the shit ones) or sizing things which benefits no one as it takes too long and is too inaccurate to be useful. Worse, it just demotivates good engineers.

Instead, teams need a mix of good and shit engineers, quick standups whose purpose is for the good engineers to realise shit ones need help, and very high level rough estimates at the project level of "this'll probably take us about 3 months". Then get out of their way but be there if they have a blocker.

Good engineers will tell you they need help, they don't need a frigging question every morning as if they're 5.

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

#48

Post by deadfoxygrandpa » Fri, Jun 16, 2023, 3:34 AM UTC

quickthrower2 wrote: post #10

My instinct is that if you can put numbers and predictions based on real world estimations, then you are estimating simple things. For example, you can estimate how long it will drive from A to B. Google maps does a brilliant job of this, showing the busy sections. Often I get there +/- a minute from what is estimated over a 60 minute journey. But estimating how long someone will take to do a project, where the proje…

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 schedule. how did that planning happen? dont tell me that was simpler than your crud app

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

#49

Post by efficax » Fri, Jun 16, 2023, 3:36 AM UTC

wellpast wrote: post #32

I might be in a 1% of engineers that believe in estimation. 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. That's fine. There is something called skills, and you can go get them. Have you made a plan? Great, then is there is some task in your plan that you can't estimate? In rare cases that might be inherently t…

the map becomes the territory here. if you have enough information to accurately estimate a project then you've already done the bulk of the work, and all you have left to do is type. The reason estimates are hard is because the work surprises you. You find out there are problems you didn't expect that must be solved to meet the stated goals. This happens all the time, it always happens on anything non trivial, which is why you have to add time to estimates beyond your initial assumptions. What experience teaches you is that this is going to happen, and it even gives you an inkling of the sorts of ways it might happen, and even better it makes it easier for you to resolve these issues when they do happen because they tend to be similar to other problems you've encountered before, but what it can't tell you is which problems you'll run into, becuase you won't run into them, until you do.

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

#50

Post by cardy31 » Fri, Jun 16, 2023, 3:37 AM UTC

keyle wrote: 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…

In this vein, my manager doesn’t appreciate when they ask for an estimate and I say “If I knew how to accurately estimate software projects I would be making millions as a consultant. But I don’t so I’m here”