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

Re: Software estimation is hard – do it anyway

#101

Post by mason55 » Wed, Jun 30, 2021, 4:20 PM UTC

lowercased wrote: post #98

mason55 wrote: post #90

Earlier quoted context omitted.

> Good and accurate estimation is not just a dev function. It requires buy in and input from the entire business stack. And in my experience, when people don't want to buy in to doing the whole process up front but they still demand some kind of commitment, the easy way to handle it is: "We can commit to a date and we'll finish whatever we finish by then, or we can commit to a scope and it will take as long as it tak…

> commit to something, but you don't know what... The problem comes in when people think they do know 'what' it is, and they're just... adamant that you 'computer people' don't 'get it'. I can't speak to all my clients - some are great - but have had some in the past that just insisted I was being obstinate or obtuse or difficult by asking clarifying questions. Then they'll take hours/days obsessing over shades of bl…

Yeah, it's definitely different if you're working on a contract basis. At least with internal stakeholders, whether you're building product, doing enterprise integrations, or building internal tooling, you just need to make sure that you have exec backup (or you are the exec). If you have buy-in then you can basically just set your team's policy and be done with it.

For contract work you have to do the process over and over. Frankly, if I was doing contract dev, I'd state it as an upfront policy and move to quickly fire any customers that didn't buy in.

Re: Software estimation is hard – do it anyway

#102

Post by jbay808 » Wed, Jun 30, 2021, 4:23 PM UTC

ziggus wrote: post #48

Estimation that isn't based on previous data - I think the article that follows this one refers to it as "Evidence-Based Scheduling" - is almost entirely a waste of time. We analyzed our five+ year history of estimates vs actual time, and our standard deviation was larger than our mean. It was ridiculous how wrong our estimates were. The problem was in what was being estimated - coding time. Developers would get aske…

Do you still have access to the data? Can you do me a favour? Can you plot (actual time / estimate) and see if the result is a lognormal distribution with a median very close to 1? In my experience, it always is.

Re: Software estimation is hard – do it anyway

#103

Post by yelling_cat » Wed, Jun 30, 2021, 4:28 PM UTC

pylua wrote: post #8

A big problem is that estimates given by developers are never treated as estimates but rather as quotes . If you miss your estimate then your employer may expect you to work extra hours to make up for the gap . Best strategy is to under promise over deliver .

I learned early in my career to never give an executive a completion date or time estimate I hadn't thought long and hard about and had full confidence in. They won't remember any of the contingencies you tacked onto your estimate or the additional features they insisted on adding to the project after you talked, but they'll never forget when you said it would be done. It's far better to annoy them in the short term by saying what you'll need to provide an accurate time frame than it is to guestimate something that will bite you later.

Re: Software estimation is hard – do it anyway

#104

Post by atatatat » Wed, Jun 30, 2021, 4:32 PM UTC

rorykoehler wrote: post #87

pylua wrote: post #8

A big problem is that estimates given by developers are never treated as estimates but rather as quotes . If you miss your estimate then your employer may expect you to work extra hours to make up for the gap . Best strategy is to under promise over deliver .

Nothing would get built if 100% accurate estimates were given. Finance would say it's too expensive and that would be that.

Awesome.

I just found another competitive advantage in my startups.

Re: Software estimation is hard – do it anyway

#105

Post by xena » Wed, Jun 30, 2021, 4:33 PM UTC

No. It feels like lying and I don't want to lie.

Re: Software estimation is hard – do it anyway

#106

Post by spyspy » Wed, Jun 30, 2021, 4:42 PM UTC

majormajor wrote: post #92

username90 wrote: post #60

Earlier quoted context omitted.

> I can give you a really really accurate estimate, but in order to do so we're going to have to spend a lot of time going through the request, building and verifying actual requirements, designing the solution and then validating it. This is almost surely wrong for most developers, or else rewrites wouldn't fail to deliver within the estimated time so often. Rewrites per definition already has a perfect specificatio…

> This is almost surely wrong for most developers, or else rewrites wouldn't fail to deliver within the estimated time so often. Rewrites per definition already has a perfect specification in the old code, just write something working the same way using a new architecture. But that is still really hard to deliver apparently. This is precisely why rewrites fail! I've never seen a rewrite where the devs had a perfect u…

On the flip side, a full rewrite is really the only way to surface and understand all of those edge cases. People seem to harp on the idea that rewrites are bad, but I find them to be a natural part of the SDLC. It's a way to refresh the mental model for the devs currently working on it, since the original dev(s) probably moved on long ago. Updating the tech or architecture itself is just a byproduct.

Re: Software estimation is hard – do it anyway

#107

Post by dboreham » Wed, Jun 30, 2021, 4:44 PM UTC

Generally, I've found that people who believe they can estimate software development projects are severely deluded. Once in a while they're not, but those cases relate to projects that are very similar to several previous projects, undertaken by the same team. Best resource on the subject: https://www.youtube.com/watch?v=v21jg8wb1eU

Re: Software estimation is hard – do it anyway

#108

Post by whimsicalism » Wed, Jun 30, 2021, 4:44 PM UTC

lowercased wrote: post #98

mason55 wrote: post #90

Earlier quoted context omitted.

> Good and accurate estimation is not just a dev function. It requires buy in and input from the entire business stack. And in my experience, when people don't want to buy in to doing the whole process up front but they still demand some kind of commitment, the easy way to handle it is: "We can commit to a date and we'll finish whatever we finish by then, or we can commit to a scope and it will take as long as it tak…

> commit to something, but you don't know what... The problem comes in when people think they do know 'what' it is, and they're just... adamant that you 'computer people' don't 'get it'. I can't speak to all my clients - some are great - but have had some in the past that just insisted I was being obstinate or obtuse or difficult by asking clarifying questions. Then they'll take hours/days obsessing over shades of bl…

This is why I prefer to work for people who are smarter than I am, rather than the reverse

Re: Software estimation is hard – do it anyway

#109

Post by tshaddox » Wed, Jun 30, 2021, 4:47 PM UTC

BjoernKW wrote: post #37

steverb wrote: post #23

Here's my beef with estimates. I can give you a really really accurate estimate, but in order to do so we're going to have to spend a lot of time going through the request, building and verifying actual requirements, designing the solution and then validating it. The process will require dev resources, business resources and probably people from the support team and will take a lot of time. I'm happy to do it. It's a…

A common misunderstanding about software creation is that code is the desired result. Hence, estimates more often than not try to predict how long it'll take to write the code that produces a desired outcome. However, in the end, code is just a very detailed specification of the design that produces a desired outcome. There's a reason why production is called production, after all: https://www.commitstrip.com/en/2016…

> However, in the end, code is just a very detailed specification of the design that produces a desired outcome.

Yes, exactly. The code is a technical specification that is so clear that a very dumb uncreative machine can follow it perfectly!

Re: Software estimation is hard – do it anyway

#110

Post by jph » Wed, Jun 30, 2021, 4:49 PM UTC

jameshart wrote: post #30

jph wrote: post #14

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

Was the name chosen because four numbers provides exactly enough ROPE for the product owner to hang you with?

Ha! The name ROPE is because a rope is a group of strands, braided together into a larger and stronger form with higher tensile strength.

With ROPE, the four numbers combine together to create a larger and stronger estimate. I do estimates for clients, and ROPE provides a way for each stakeholder to see that estimates are really ranges of probabilities.