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

Software estimation is hard – do it anyway

jacobian.org

Post reply on HN
Print view View original

211–220 of 231 posts

Re: Software estimation is hard – do it anyway

#211

Post by bcrl »

shakezula wrote: post #195

I absolutely loathe software estimates. They put engineers in a damned if you do, damned if you don't scenario that isn't even in their full control anyway. I think this is one of the things that Shape Up got the most absolutely correct - inverting the relationship between an estimate and time. We've been asking the wrong question all along: Instead of asking "how long will X take?" you should be asking "How long do…

I'm the opposite. I find putting an estimate together makes me think through the design and ensure that the scope is limited enough to be viable within the schedule. By having a rough idea of all the tasks that have to be done, progress against those tasks can be measured. Knowing how far along the project is then gives feedback into development to know when and where pressure needs to be applied.

Granted, this whole thing works for me as I happen to thrive under pressure.

Re: Software estimation is hard – do it anyway

#212

Post by bcrl »

agentultra wrote: post #31

One major “secret” to advancing in a technical career is learning how to give accurate estimates. It certainly has been for me... Seems like there's a hint of survivorship bias. The author will eventually give a bad estimate. There's no secret or trick otherwise it would be widely known by now. Even the video games industry has been coming around on this in the last decade. This is a sector of the software industry f…

A good developer also has to know how to spot when a project will fail.

Re: Software estimation is hard – do it anyway

#213

Post by dws »

A big benefit from putting in the effort to estimate is from the side-effects having to get clear on the what the problem is and what constraints apply. So much useful information gets flushed out when you're both under pressure and are trying to give a reasonable estimate.

Then, often, toss the estimate.

Re: Software estimation is hard – do it anyway

#214

Post by BigJono »

Buttons840 wrote: post #83

A problem is that people have different things in mind when they ask for estimates. For some, an accurate estimate would mean that 50% of the time you're over and 50% of the time you're under. But management too often takes this type of 50/50 estimate and then makes all kinds of promises and contracts based on it. If you want an estimate that we're going to hit 99% of the time, that is going to be much much higher. M…

IME they hear "there's a 95% chance it'll be done between 5-7 months", when the real 95% interval is more like 2-15 months.

Re: Software estimation is hard – do it anyway

#215

Post by shakezula »

bcrl wrote: post #211
shakezula wrote: post #195

I absolutely loathe software estimates. They put engineers in a damned if you do, damned if you don't scenario that isn't even in their full control anyway. I think this is one of the things that Shape Up got the most absolutely correct - inverting the relationship between an estimate and time. We've been asking the wrong question all along: Instead of asking "how long will X take?" you should be asking "How long do…

I'm the opposite. I find putting an estimate together makes me think through the design and ensure that the scope is limited enough to be viable within the schedule. By having a rough idea of all the tasks that have to be done, progress against those tasks can be measured. Knowing how far along the project is then gives feedback into development to know when and where pressure needs to be applied. Granted, this whole…

> thrive under pressure.

I actually would say I do too, but I also appreciate deadlines for the time compression effect that they instill that you can't get from anything else.

> I find putting an estimate together makes me think through the design

I agree, and I'm not advocating for ignoring all of those details for a ticket or project. I'm just saying that the important thing is to flip the conversation. All of those things should be known regardless of the time question.

Re: Software estimation is hard – do it anyway

#216

Post by imbnwa »

musicale wrote: post #176
Animats wrote: post #150

Paid overtime will fix scheduling. Scheduling is bad because the cost falls on the employees, not the employer. If crunches resulted in time and a half, double time, and triple time, scheduling would get fixed. As I've pointed out before, film scheduling is an established discipline. Making a movie is much more complex than a software project. There are a lot of moving parts. Things get changed. There are people prob…

> Making a movie is much more complex than a software project. Software design and development is more like writing the books that the script was based on. Think Song of Ice and Fire, but 100,000 pages long and written simultaneously by a hundred authors.

Software Dev is The Wheel of Time, got it

Re: Software estimation is hard – do it anyway

#218

Post by Jenk »

mcavoybn wrote: post #209
Jenk wrote: post #140

Earlier quoted context omitted.

We don't even need to pretend it is an outside-of-technical-people problem. Developers (and just people in general) are just as guilty at mis-estimating their own capacity for work. By this I mean we forget we have other things - we don't accurately account for meetings and side-tasks. We underestimate the complexity of even simple tasks. We don't account for the flames we fight habitually without much consideration.…

I don't think the point of lowercased's comment was that devs don't underestimate tasks to the same degree that "outside-of-technical-people" might. They are saying that "outside-of-technical-people" don't have the experience to understand how difficult it is to give an accurate estimate or how much pressure is put on devs to agree to a deadline and take responsibility for making something happen by that date. This i…

That's fair - my intention was to say that non-engineers aren't any worse than engineers. I've seen the same puzzled look and demands from development teams that are requesting changes from other development teams.

Open source projects are rife with developers demanding the near-impossible from contributors/maintainers, etc. (but plenty of examples people not being dicks as well)

Additionally, they can often be worse (toxic) about it precisely because they are developers themselves, and so think they have that understanding and start acting the alpha.

Re: Software estimation is hard – do it anyway

#220

Post by tiagogm »

al2o3cr wrote: post #125
tiagogm wrote: post #93

Earlier quoted context omitted.

Kanban lends itself well to this. Breaking down work into similarly sized tickets/units can, over time, be used to predict delivery/capacity (which one can use Cycle time to calibrate) Even neater with enough data it becomes possible to use Monte Carlo simulations to give you confidence intervals on how much can you do or how long you will take to do X amount of work. https://kanbanize.com/kanban-resources/kanban-ana…

Breaking down work into similarly sized tickets/units can, over time, be used to predict delivery/capacity IMO "can break up work into similarly-sized units" is equivalent to "can estimate accurately". Re: that article - I can't imagine many things LESS accurate than "we have 104 tasks on the board and each team member's cycle time is 2 days so we can finish all the tasks with 10 people working for 20.8 days". Yeah,…

True, I do find it easier and a less time consuming to break a large piece of work in around 2day chunks (for example) than using different sizes or trying to decide if something is 3 or 5.

In the end, regardless of whatever scoring strategy you use it should always be team centric, rather than individual.

It is possible to say, over the past 6 months, and X tickets, our team has had a Median/Avg cycle of around 2days. If team breaks future work in similar sized chunks, it can very fairly confidently predict how long they will take to do X more tickets, assuming similar conditions.

The added benefit of using small chunks of time, is that one does not need to be super accurate (in most scenarios), it can be 1 or 4 days, all it matters is it's possible to give window of estimation (based on actual data, not guesses) with a certain degree of confidence. (which will naturally become even more consistent over time)

Post reply on HN