Software estimation is hard – do it anyway • Hacker News Board

Re: Software estimation is hard – do it anyway

#11

Post by varjag » Wed, Jun 30, 2021, 12:21 PM UTC

bendauphinee wrote: post #6

varjag wrote: post #4

Earlier quoted context omitted.

People love to conflate research with development out of "R&D", but the latter is a lot more predictable than the former. Repeatable, well trodden domains are 99,9% of development work out there.

The problem has always been that while the ground is well trod, the path is never clear. There are hundreds of ways to build any one widget, not even counting that the widget you start building isn’t the one they wanted in their head (but not in the spec).

Sure, that's why estimation is usually not trivial. But still a lot easier than when you have to invent a new kind of widget first.

Re: Software estimation is hard – do it anyway

#12

Post by AndrewDucker » Wed, Jun 30, 2021, 12:22 PM UTC

helsinkiandrew wrote: post #7

Software estimation is only hard when you don't understand what you have to do or how it will be done. Just keep breaking the problem down into sub units that you or your team understand and can fairly accurately understand the effort and risk of (because they've been done before)

And when there are chunks that you haven't done before?

Or when breaking it down will require going to a level of detail that means basically fully designing/writing your system in order to estimate it?

Re: Software estimation is hard – do it anyway

#13

Post by codingdave » Wed, Jun 30, 2021, 12:24 PM UTC

I do believe a rough estimate is important. But detailed estimates are not always helpful. It is wise to understand what decisions and actions will be driven from an estimate. If it is a general swag to tell an exec when something might ship, that is one estimate. If it is a level of effort question to know which of two equally important features can be delivered more quickly, that is a different estimate. If you are trying to order work to be done in a way to optimize assignments of work to team members, that is something else. And if you simply have to do some work to keep a product afloat and there is no possible way to avoid doing the work, then the estimate is only for reporting purposes and should not block getting started on the work.

Estimates do matter - but blindly doing the same type of estimate for all tasks is missing the point. (Which is why I feel story pointing is overdone.)

Re: Software estimation is hard – do it anyway

#14

Post by jph » Wed, Jun 30, 2021, 12:25 PM UTC

The best estimation technique I've seen is ROPE: Realistic, Optimistic, Pessimistic, Equilibristic. It's fast to ballpark, effective solo or with teams, great for PMs and managers, and able to go directly into critical chain scheduling or monte carlo simulations.

https://github.com/SixArm/sixarm_project_management_rope_est...

Re: Software estimation is hard – do it anyway

#15

Post by onion2k » Wed, Jun 30, 2021, 12:27 PM UTC

I kind of agree with the premise of the article. Having "enough experience" can lead to more accurate estimates in some cases, because the thing that makes estimates inaccurate are the unknown aspects of the story. More knowledge about the domain, the codebase, the expectations of the client, and so on do make your estimates better because that knowledge simply means there are fewer unknown aspects.

For stories that have significant unknowns you'll still be wrong though.

However, even then it's still worthwhile providing estimates. The benefit comes from knowing how wrong you are. If you look at a story and have a guy feeling that it's quite simple but it actually takes far longer than the estimate that's useful data. It tells you that there's some aspect of the story that you weren't expecting, which can point to understanding where unknowns lie, or it means you thought the code was simpler than it really is so maybe there's some technical debt to be refactored, or it means that you failed to fully understand the implications of how far-reaching the story was so you should have done more upfront research. All those things can inform the next estimates you provide.

Re: Software estimation is hard – do it anyway

#16

Post by karmelapple » Wed, Jun 30, 2021, 12:35 PM UTC

onion2k wrote: post #15

I kind of agree with the premise of the article. Having "enough experience" can lead to more accurate estimates in some cases , because the thing that makes estimates inaccurate are the unknown aspects of the story. More knowledge about the domain, the codebase, the expectations of the client, and so on do make your estimates better because that knowledge simply means there are fewer unknown aspects. For stories that…

On our team, not only is estimation worthwhile, but the process of coming to a collective team consensus on an estimate is very worthwhile.

We have our product owner in the estimation session (we use planning poker), we discuss requirements, assumptions, sometimes even a potential approach or two to building a solution. That process frequently leads to discovering unknown unknowns, new requirements, and sometimes even reevaluating whether we need the change.

Estimation discussions involving a big chunk of the team can be truly useful.

Re: Software estimation is hard – do it anyway

#17

Post by methyl » Wed, Jun 30, 2021, 12:39 PM UTC

karmelapple wrote: post #16

onion2k wrote: post #15

I kind of agree with the premise of the article. Having "enough experience" can lead to more accurate estimates in some cases , because the thing that makes estimates inaccurate are the unknown aspects of the story. More knowledge about the domain, the codebase, the expectations of the client, and so on do make your estimates better because that knowledge simply means there are fewer unknown aspects. For stories that…

On our team, not only is estimation worthwhile, but the process of coming to a collective team consensus on an estimate is very worthwhile. We have our product owner in the estimation session (we use planning poker), we discuss requirements, assumptions, sometimes even a potential approach or two to building a solution. That process frequently leads to discovering unknown unknowns, new requirements, and sometimes eve…

Can you just keep the process but skip the estimation part?

Re: Software estimation is hard – do it anyway

#18

Post by PetahNZ » Wed, Jun 30, 2021, 12:41 PM UTC

onethought wrote: post #2

‘You can get good at estimation’ Only if you work in an extremely repeatable well trodden domain. If you are so skilled at estimation, I’m sure Tesla would love you to tell them how long FSD will take and would pay a premium!

I can estimate how long FSD will take. Now where do I get the pay check?

Re: Software estimation is hard – do it anyway

#19

Post by sanguy » Wed, Jun 30, 2021, 12:41 PM UTC

To accurately estimate means developers and product management have collectively discussed the requirements to a level everyone understands clearly. Without this an estimate is as accurate as a weather report for 90 days out.

A good estimate may also require "spiked" to test concepts to get to a reasonable estimate.

I'm currently in a project that is terrible as the development team provides estimates without even reviewing the requirements and now "18 months late" with many pissed off stakeholders. It is a caustic situation. People are quitting the company due to the politics, frustration, and pressure due to this.

Re: Software estimation is hard – do it anyway

#20

Post by throw-8462682 » Wed, Jun 30, 2021, 12:42 PM UTC

tut-urut-utut wrote: post #9

Don't do it if you can avoid, especially if company culture is to treat rough estimation as a promised deadline. If you can't avoid giving estimation, try to pad it as much as possible, add every single uncertainty to the task list, and estimate very conservative. Add enough time for testing, communication, work on change requests. And even after the original estimate is approved / published be sure to communicate up…

Good estimates are critical to plan dependent activities and setting customer expectations. If we don’t estimate then we are saying that software engineering is not an engineering discipline. You can have that view, but in my experience it does not lead to good outcomes.

If I can assume you’re an SDE for a moment, I actually agree with the part of you not providing estimates. Recently I’ve done the initial estimate for projects exclusively between SDM and PMT with no engineers involved. It has been a lot more reliable and it seems that SDEs are very happy to be absolved of this responsibility. This does require SDMs and PMTs with a good amount of experience.