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

131–140 of 231 posts

Re: Software estimation is hard – do it anyway

#131

Post by jstepka »

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.

Re: Software estimation is hard – do it anyway

#132

Post by vosper »

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

> IMO "can break up work into similarly-sized units" is equivalent to "can estimate accurately".

Yeah, agreed. What I've always seen is "break up work into logical units, ideally as small as possible" which always ends up with a mixture of tickets of different sizes.

Re: Software estimation is hard – do it anyway

#133

Post by snarf21 »

mtippett wrote: post #122
snarf21 wrote: post #38

Earlier quoted context omitted.

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.

That's actually a good hack. I tend to take a similar approach, but using approximate days in a fibonacci sequence. Start at the high end, will it take... years: NO quarters: NO months: erm... NO. weeks: maybe days: Unlikely hours: Ha. No. So you end up with a range (days?-weeks-months). That's too broad, what could go wrong to avoid making it months long project (well we could investigate X, Y, and watch for Z). Wha…

Yeah, I always think about my structure as "some small number of h/d/w/m/q/y". I count 1 week the same as 3 weeks in terms of scale. ymmv

Re: Software estimation is hard – do it anyway

#135

Post by majormajor »

spyspy wrote: post #106
majormajor wrote: post #92

Earlier quoted context omitted.

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

That's an interesting take, and getting that context is valuable, but it seems like there really should be a way to do that that's less disruptive and destructive to "actually being able to deliver new features" than a full rewrite that stops the world for months or longer...

Re: Software estimation is hard – do it anyway

#136

Post by waylandsmithers »

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. (And then take the next day off or come in at noon or whatever.)

For reasons I will never understand, with three days left in the month a certain director would spend the whole day running around with a spreadsheet of all the reports that were open and ask people for a red/yellow/green estimate of whether they would be done. The next day and the next he'd repeat the process to get his most accurate estimate of the monthly revenue.

Then two days later, the controller would just hand him the actual revenue numbers for the month ended.

Re: Software estimation is hard – do it anyway

#137

Post by amatecha »

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 frustrating to get that push-back when it's like, those clarifying questions are just the tip of the iceberg and are required simply to get started -- basically the whole rest of the project is going to be resolving "nitpicky" details like that until it's done.

Re: Software estimation is hard – do it anyway

#138

Post by mannykannot »

Personally, I have found it useful to make private estimates, and then be honest with myself about why I did not meet them. It has made me a better developer, and incidentally also better at estimating.

What, if anything, I say about these estimates to anyone else depends on the culture of the environment, but the experience of estimating has made me better at explaining why it is going to take longer than you think, when that case needs to be made.

Re: Software estimation is hard – do it anyway

#139

Post by monkeydust »

Business here.

Guess what we get it's hard but we have to do it so we can plan release, usage (with Sales) and spit out revenue targets to justify the initial spend.

It's all about confidence of estimates. Many small things are easy to estimate and have high confidence. We're good at that stuff.

Where it gets super difficult are greenfield new products that span across multiple teams,both engineering and business. Without burning your entire budget on the estimation process you just have to have exceptional buy-in from all teams and start working, that's the best way.

Where things get tricky are when one business vertical suddenly has a new urgent #1 priority during the build and has to divert away attention and resource. Everyone can lose momentum so takes some business and engineering craft to hold it together.

All part of the gig.

Re: Software estimation is hard – do it anyway

#140

Post by Jenk »

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…

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. We don't even recognise the amount of time we spend just relaying and receiving information. Those intriguing and important (and still work related just not explicitly about the task we have estimated) slack messages and water cooler moments aren't accounted for in our estimates.

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

This is all before we even begin to appreciate that even perfect world estimates are hard because, as Ron Jeffries said:

    Even with clear requirements — and it seems that they never are — it is still almost impossible to know how long something will take, because we’ve never done it before. If we had done it before, we’d just give it to you.
Post reply on HN