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

Re: Software estimation is hard – do it anyway

#151

Post by ppeetteerr » Wed, Jun 30, 2021, 7:07 PM UTC

rantwasp wrote: post #128

ppeetteerr wrote: post #117

At the risk of being downvoted, I would argue that working on a project without first estimating the work is not engineering. It's coding. A thoughtful estimate shows care in understanding the project and how it fits into the greater whole of the existing platform. It allows all members of the company to trust in the timelines of the engineering team and align their work to meet the milestones. An estimate is by no m…

here is the problem: estimating is also work. breaking down the work is hard work. sometimes it takes more to break down and think things through than to do the work. the fundamental problem is that management does not want estimates. they want quick estimates (ie close to zero effort) and after that they turn around and use those estimates as deadlines. now as a developer what are you supposed to do? you’re gonna ge…

As a manager and I can tell you that the push back to estimates is primarily from engineers and cheap company owners ("why spend time estimating when I/they can code?"). Estimating, wire framing, documenting, manual testing, security testing, etc are all hard but necessary.

If you don't schedule time to estimate, the estimates are worthless. Rule of thumb, anything that can be done by one engineer in less than 1 month should take about 1 day to estimate, anything under 3 months, one week, anything longer should take up to a sprint (2 weeks). As a manager with experience, you should roughly know what level of time needs to be spent by your team planning their work prior to executing. Chances are, in the estimation work, the engineer(s) will discover questions that have not been answered by the product specification that need clarification. And that's the whole point: getting as clear of a picture as possible.

As for any manager that thinks they can squeeze value is naive about what software engineering is. This is not a manufacturing line.

Re: Software estimation is hard – do it anyway

#152

Post by bastardoperator » Wed, Jun 30, 2021, 7:11 PM UTC

Hell No, for the most part in my limited experience, they're not estimates, we should really stop calling them that. They're at best guesses at worse they're coupled with excessive padding and extreme waste.

I don't have any beef with it being hard. I have a major beef with it setting invalid expectations, having no basis in calculated fact, and overall being useless/time consuming to the people having to meet these deadlines and participate in said "agile" rituals.

I'm all about capacity. If we can understand what a team is capable of or the capacity of said team, we don't have to guess how much work they agree or don't agree to do or force them to use a crystal ball at the weekly séance.

Re: Software estimation is hard – do it anyway

#153

Post by ppeetteerr » Wed, Jun 30, 2021, 7:15 PM UTC

bastardoperator wrote: post #152

Hell No, for the most part in my limited experience, they're not estimates, we should really stop calling them that. They're at best guesses at worse they're coupled with excessive padding and extreme waste. I don't have any beef with it being hard. I have a major beef with it setting invalid expectations, having no basis in calculated fact, and overall being useless/time consuming to the people having to meet these…

You can only measure capacity if you know the size of the work you're taking on. If you don't, what does capacity even mean?

Re: Software estimation is hard – do it anyway

#154

Post by pwthornton » Wed, Jun 30, 2021, 7:16 PM UTC

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…

This is generally why I don’t see a ton of value in trying to do accurate estimation. You’ll get better velocity and delivery not wasting your time on all of the faux story point estimating that scrum and other systems do.

The most proven way to do accurate estimation is to base new estimates off of previous delivered work (i.e. we’ve built this suspension bridge design before and it took us this long, so we believe a similar bridge under similar conditions would take similar amount of time). This is not what most places do (and most places don’t spend a lot of time after the fact really seeing how long each phase and part of the process took).

I’d argue that estimates should be removed from day-to0-day engineers and placed with program managers or others whose job is to see how long work has taken and make schedules and estimates off of previous known work.

The other way to get more accurate estimates is to build in systems and processes that require less and less custom work over time. So many software shops and tech companies never invest in this and every new major feature or project is heavily custom work.

Re: Software estimation is hard – do it anyway

#155

Post by ppeetteerr » Wed, Jun 30, 2021, 7:26 PM UTC

pwthornton wrote: post #154

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…

This is generally why I don’t see a ton of value in trying to do accurate estimation. You’ll get better velocity and delivery not wasting your time on all of the faux story point estimating that scrum and other systems do. The most proven way to do accurate estimation is to base new estimates off of previous delivered work (i.e. we’ve built this suspension bridge design before and it took us this long, so we believe…

Depends on what you mean by accuracy. There is no bullseye with estimates. It's a means to set expectations and to show that you've thoughtfully analyzed the work.

Part of your argument rests on reducing novelty. However, that's already covered by the myriad of manufacturing process improvement books. Programming is unique because every project is novel. Any migration, any integration, is going to be heavily dependent on company culture and environment.

Like it or not, estimates are necessary to weight A against B, to scope, to plan marketing releases, to compete, to sell, to budget, etc. You may not get value from it as a coder, but that doesn't mean that there is no value in it.

Re: Software estimation is hard – do it anyway

#156

Post by sharken » Wed, Jun 30, 2021, 7:31 PM UTC

mason55 wrote: post #90

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…

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

It sounds very much like the constraints of the Project management triangle:

https://en.m.wikipedia.org/wiki/Project_management_triangle

It's probably the first time i have seen estimation described so clearly as a choice between scope or date.

Am still trying to figure out how something like SAFe works with the above, the gut feeling is "not great".

Re: Software estimation is hard – do it anyway

#157

Post by pseudalopex » Wed, Jun 30, 2021, 7:38 PM UTC

zerkten wrote: post #54

One person's estimate is different from another person's estimate. The hole that most developers dig for themselves starts with a fixation on having perfect numbers and that they'll be punished if they don't have these. Estimation is often a part of negotiation separate from commitments, but developers treat it as a pure analysis game. This results in punishment for poor communication. The punishment starts when they…

It's rarely developers turning estimates into commitments. Many even have stories of managers refusing to accept estimates because the deadline was decided already.

A developer trying to communicate a clear perspective that does not make commitments will be seen as attempting to weasel out of a discussion in such an organization.

Customers understand 95% confidence better than they understand coding spikes in my experience.

Re: Software estimation is hard – do it anyway

#158

Post by pseudalopex » Wed, Jun 30, 2021, 7:38 PM UTC

TameAntelope wrote: post #120

cosmotic wrote: post #113

> One major “secret” to advancing in a technical career is learning how to give accurate estimates If Google, Microsoft, Apple, Blizzard, etc can't produce accurate estimates despite employing 'the best of the best', wouldn't that imply it's a nearly impossible task? I can see getting order-of-magnitude estimates, but nothing more accurate than that.

Plans are nothing, planning is everything. You have to try, even if you know it's going to be bad/inaccurate.

That isn't what the author said though.

Re: Software estimation is hard – do it anyway

#159

Post by bastardoperator » Wed, Jun 30, 2021, 7:41 PM UTC

ppeetteerr wrote: post #153

bastardoperator wrote: post #152

Hell No, for the most part in my limited experience, they're not estimates, we should really stop calling them that. They're at best guesses at worse they're coupled with excessive padding and extreme waste. I don't have any beef with it being hard. I have a major beef with it setting invalid expectations, having no basis in calculated fact, and overall being useless/time consuming to the people having to meet these…

You can only measure capacity if you know the size of the work you're taking on. If you don't, what does capacity even mean?

You're never going to know that. I rather track for example DORA metrics like MLT or DF versus tshirt sizes.

Re: Software estimation is hard – do it anyway

#160

Post by brightball » Wed, Jun 30, 2021, 7:42 PM UTC

tomrod wrote: post #95

brightball wrote: post #91

Earlier quoted context omitted.

How so?

With computers and dev tools, trying to get the current PI complete.

If that happens you’re just supposed to include what is still to be done in the next PI while you stop everything for PI planning.

There are too many people involved to just skip it to keep working.