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

161–170 of 231 posts

Re: Software estimation is hard – do it anyway

#161

Post by neutronicus »

bartread wrote: post #64
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…

Years ago, in a former life, I built a project boilerplate that included all the non-development tasks required to build and ship a new version of a product that I used to build out all my project plans. There's all this (important) "guff" that people in the development often don't think about and don't care about that you absolutely have to take into account if you want to get even close to a sensible ship date. Som…

> front-load all the riskiest work

This is important.

I'm in the middle of a dev cycle where I'm doing the riskiest work, and other people depend on it.

Unfortunately, I think I allowed myself to get pulled into the design process too much, when I should have been prototyping like months before I started doing so in actuality.

I allowed myself to get blocked by a bunch of design decisions I could have easily adapted my implementation to conform with, and in turn blocked a few people downstream of my (risky) work.

I'm lucky that what I did is pretty "flashy," because I think management is just happy to have anything at all for the feature I was working on.

Re: Software estimation is hard – do it anyway

#162

Post by tikhonj »

beckingz wrote: post #32
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 .

Even estimates that are requested explicitly as estimates and not quotes have a tendency to be used for planning other dependencies. Once other dependencies are scheduled around a estimate, missing that deadline incurs rescheduling costs so no one wants to see it missed.

And yet, in my experience, even people who recognize this focus hard to improving estimates and "accountability", but rarely seriously try to reduce dependencies.

I tend to operate on the opposite principle, to the point that I believe it is worth doing substantial amounts of seemingly redundant or throw-away[1] work to turn hard dependencies into soft dependencies. But you have to have both a business organization and a software architecture that can support this.

[1]: Really, "throw-away" just means "temporary", and all our work is temporary—the question is just how temporary.

Re: Software estimation is hard – do it anyway

#163

Post by kyriakos »

ItsMonkk wrote: post #80
throw-8462682 wrote: post #20

Earlier quoted context omitted.

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

> customer expectations My favorite moments from events like WWDC are when you are introduced to some really cool feature or app for the first time, and then the speaker goes "available today". The fans love it, the news sites love it, whenever you can immediately try out something the hype for that product goes up 10x. When you only show the product when it's finished, you no longer need to estimate anything. > depe…

Regarding the WWDC comment, of course an estimate was needed in the first place cause WWDC day was also the projects deadline.

Re: Software estimation is hard – do it anyway

#164

Post by cpeterso »

snarf21 wrote: post #38
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…

Well said. My current rule based on experience is that estimates should only be hours/days/weeks/months/quarters/years with NO numbers. It is to give a sense of scale and effort so it could be prioritized and/or modified. If they want exact dates, then it is like you said, several days/weeks to go get an accurate date. I only wish that the sales team had to commit to closing dates the same way software teams do.

I really like your suggestion to use hours/days/weeks/etc without numbers. A similar suggestion I read for estimating (originally outside the context of software projects) was to use numbers with just one significant digit, so your estimate options would jump from 8, 9, 10, 20, 30, ...

The estimation mention I dislike the most is "t-shirt size". There is no clear relationship between S/M/L/XL. At least story points let compare two tasks. If you try to give t-shirt sizes points (e.g. "M = 2*S"), then you might as well skip the t-shirt abstraction and just use story points.

Re: Software estimation is hard – do it anyway

#165

Post by tomrod »

brightball wrote: post #160
tomrod wrote: post #95

Earlier quoted context omitted.

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.

And yet!

Re: Software estimation is hard – do it anyway

#166

Post by akiselev »

Frost1x wrote: post #25
throw-8462682 wrote: post #20

Earlier quoted context omitted.

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

>If we don’t estimate then we are saying that software engineering is not an engineering discipline. Not a mature engineering discipline. If you can budget a planning phase in development that allows you to quickly explore the unknown unknowns and known unknowns to investigate critical bottlenecks and uncertainty before estimating and you're able to lock that down with a set of features, then I think you can create d…

> Not a mature engineering discipline.

The concept of standardized parts and assembly lines is less than a century old. How accurate do you think their estimates were before they figured out the basic principles of repeatability?

The "mature" engineering disciplines literally just punted on the problem for several centuries, only giving birth to systems engineering [1] in the mid 20th century because they were so bad at it and everyone's back was against the wall in WWII. Before it became its own recognized field, project management in engineering was worse than it is in software now.

Not coincidentally Bell Labs - the company that basically kick started the computing industry - was also the biggest player in the formalization of systems engineering. Since then its been adapted as the methodology for managing engineering projects by everyone from civil engineers to NASA [2]. Any estimate you see for a nontrivial project from the past half century isn't the result of mechanical, civil, or electrical engineers but the product of systems engineers.

[1] https://en.wikipedia.org/wiki/Systems_engineering

[2] https://www.nasa.gov/connect/ebooks/nasa-systems-engineering...

Re: Software estimation is hard – do it anyway

#167

Post by ppeetteerr »

bastardoperator wrote: post #159
ppeetteerr wrote: post #153

Earlier quoted context omitted.

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.

Aren't those DevOps KRs? I would track KRs even in software engineering: releases without incident, estimate to reality ration for future planning, etc

Re: Software estimation is hard – do it anyway

#168

Post by pseudalopex »

dllthomas wrote: post #148

In my experience there are three things that often get conflated around software estimates: 1 Effort versus calendar time. 2 Estimate versus commitment. 3 Confidence level - are we talking P50? P99? P100 under some set of assumptions? I don't think I've ever worked in a setting where everyone shared the same understanding on all of these points.

Very true. And lots of people don't even understand the differences on their own.

Re: Software estimation is hard – do it anyway

#169

Post by dllthomas »

pseudalopex wrote: post #168
dllthomas wrote: post #148

In my experience there are three things that often get conflated around software estimates: 1 Effort versus calendar time. 2 Estimate versus commitment. 3 Confidence level - are we talking P50? P99? P100 under some set of assumptions? I don't think I've ever worked in a setting where everyone shared the same understanding on all of these points.

Very true. And lots of people don't even understand the differences on their own.

Agreed, but that's the comparatively easy part...

Re: Software estimation is hard – do it anyway

#170

Post by catwind7 »

what I've seen a lot over the years is that an engineer gets asked about timeline, thinks for about 10 seconds, blurts something out, then if it's off (too short) they bust their asses / cut corners trying to hit their own estimate. Since estimates are usually optimistic, I tend to see a lot of over time and/or corners cut.

there's certainly an element of personal pride in that dynamic I think. You're asked to give an estimate. You give it. You now feel like you've staked your professional rep to it.

the author shares his method for coming up with estimates, and it looks like an offline process that involves more than a gut check. I think for sufficiently large features we (eng managers, eng peers) should encourage engineers to _not_ give on the spot estimates given we know how difficult it is to estimate.

Post reply on HN