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

201–210 of 231 posts

Re: Software estimation is hard – do it anyway

#201

Post by Pokepokalypse »

Jenk wrote: post #140
lowercased wrote: post #98

Earlier quoted context omitted.

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

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

>Most estimates are inherently given on a "if I am in a perfect working environment with no interruptions" basis and we don't even acknowledge _that_.

I had the experience of working at a company that had the practice of rigorously tracking engineer-hours. Through a time-card system. (this was for billing our clients). This way we always had a paper trail of how long we spent on a given task or project, and it was generally "against the rules" to bill hours you weren't directly working on that project.

This led to having an awareness of that imperfect working environment, and was a powerful enabler of making good estimates.

On the other hand: that documentation effort wasn't free either.

Re: Software estimation is hard – do it anyway

#202

Post by jsmeaton »

This is just the first article in the series. I'd recommend reading all 4 articles before rebuking this one.

https://jacobian.org/series/estimation/

For example, here's an except from the SWAG article:

> The tradeoff is time: estimation techniques, including mine, require some time to produce any level of accuracy.

> Sometimes, though, it’s less important that an estimate be accurate than that it be quick.

Re: Software estimation is hard – do it anyway

#203

Post by nitwit005 »

jstepka wrote: post #131
rossdavidh wrote: post #27

Look, it's just a requirement to know the weather 3 months in advance. A lot of money is riding on this: agricultural impacts, shipping, the effect on consumer behavior and power generation requirements. Doing without accurate weather reports 3 months out is just not acceptable. Sure, it's hard, but you have to just do it anyway, because it's so important. ... Except weather reports 3 months out are not reliable, unl…

it's so weird. i know it'll be cold in feb in minnesota. i know this because i have experience. and that experience translates into my ability to give guidance. if you want to be taken serious, you need experience to be able to estimate.

This is the "it never rains" strategy of weather reporting. On most days, it's not raining, so you'll be right most of the time.

Some may claim they have personally experienced rain, so your model must have some faults, but just ignore those plebeians.

Re: Software estimation is hard – do it anyway

#204

Post by Pokepokalypse »

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…

Sounds like you re-invented PERT.

Re: Software estimation is hard – do it anyway

#205

Post by slumdev »

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…

You are the kind of PM that I will gladly give estimates to.

The others, not really.

Re: Software estimation is hard – do it anyway

#206

Post by sanguy »

gortok wrote: post #21
sanguy wrote: post #19

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

It’s just “a spike” or “spike”.

Yea sorry, autocorrect strikes.

Re: Software estimation is hard – do it anyway

#207

Post by sanguy »

bigwavedave wrote: post #49
gortok wrote: post #21

Earlier quoted context omitted.

It’s just “a spike” or “spike”.

> It’s just “a spike” or “spike”. I imagine the OP meant "spikes" and either accidentally hit the 'd' instead of the 's' or simply fell victim to autocorrupt.

Yes, thanks!

You'd make a great developer with the perception of the error cause before confirmation ;)

Re: Software estimation is hard – do it anyway

#208

Post by sanguy »

rorykoehler wrote: post #96
sanguy wrote: post #19

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

For most saas out there, once all the requirements are that well understood the product is already 70% built.

This is very true.

A great product manager is as priceless as a great developer.

Re: Software estimation is hard – do it anyway

#209

Post by mcavoybn »

Jenk wrote: post #140
lowercased wrote: post #98

Earlier quoted context omitted.

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

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 is compounded by the fact that stakeholders are unwilling to define or commit to a detailed set of features or acceptance criteria. The bigger the project, the more painful and difficult this becomes. Stakeholders say "Make it faster!!!" then engineers say "We agree!!! any ideas on how?".

Re: Software estimation is hard – do it anyway

#210

Post by solveit »

waylandsmithers wrote: post #136
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…

My own personal anecdote: I worked for a company that produced reports for insurance adjusters. Sometimes the reports were small enough to take an hour, and some large enough to take a week to produce. For some reason the company was obsessed with the "month-end" cycle- people on the last day of the month would work overtime until midnight and occasionally skip usual quality control checks to get things out the door.…

Perhaps an insider trader trying to outpace all the other insider traders?
Post reply on HN