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

Software Estimation Is a Losing Game (2014)

rclayton.silvrback.com

Post reply on HN
Print view View original

21–30 of 50 posts

Re: Software Estimation Is a Losing Game (2014)

#21

Post by wai1234 »

kzhahou wrote: post #8

I can estimate some tasks very accurately. I know that adding this new flag to my system will take a day. Other tasks I can accurately say I don't know how long they'll take. This new feature is... a couple of weeks? This new application is... a few months? I can roughly guess (estimate!) but there's a wide certainty margin. That uncertainty is never built into the mathematical model used by project managers, which i…

So, small tasks you CAN estimate, large ones not so much. Perhaps the technique to use is right in front of you: decomposition.

Re: Software Estimation Is a Losing Game (2014)

#22

Post by jacques_chester »

cpitman wrote: post #20
jacques_chester wrote: post #13

Earlier quoted context omitted.

I worked on an estimation tool[1] inspired by PERT 3-point estimates for a while, simply because there weren't any when I went looking one time. It was a lot of fun reading up on the estimation literature in various disciplines. Personally I think that the real magic of PERT 3-point estimation is the "unpacking effect" -- making people think about the subtasks of a headline issue. When I'm in situations where I point…

The other part of 3 part estimates that I like is that it forces everyone to consider the worse case. What can go wrong? What risks are there to this task? And only then do we talk about how long we think it will probably take. The problem I have always had afterwards is communicating the results. Most people I've worked with cannot intuitively grasp confidence levels (90% vs 95% vs ...). They also invariably want a…

Culture, really. Trust.

Where I work, Engineering owns the estimates. No ifs, buts or maybes. We own estimates. Product managers have unlimited ability to reprioritise, but we and we alone get to say how hard it's going to be.

That said, another secret is: use story points. They are dimensionless units that are only meaningful within a single project. As soon as you give dollars or days, everybody has an opinion or an agenda.

But if you use points and project based on velocity, it's hard to negotiate. Because you're not negotiating. Those are the actual numbers. The actual historical data, staring you in the face.

(Edited for clarity)

Re: Software Estimation Is a Losing Game (2014)

#23

Post by _xnmw »

wai1234 wrote: post #19

I have to laugh when I see these posts. So, software development is a special activity that should not be constrained by budgets or deadlines (or estimates)? Where do I sign up? There are so many strawmen here I can't possibly address them all. If you can't provide a credible estimate for a piece of work, you either a) aren't very good, b) don't properly understand the work to be done, or c) perceive some aspect of t…

"So, software development is a special activity that should not be constrained by budgets or deadlines (or estimates)?"

Of course it is constrained, but how can you estimate it? Because "software development" is the continuous process of converting a real world idea into instructions that are so tiny and specific that a computer can understand them. Obviously you can't know in advance what those instructions are, or you've already written the program. When do you stop "pushing back against poorly defined projects"? You can literally continue asking for more specifics until the project is complete. This is different from other areas of engineering, because almost NOTHING demands preciseness like a computer does.

"Estimating work and committing to those estimates is what a professional does. Deal with it."

The reality is, we have been trying to deal with, for decades. And failing badly. The author is suggesting (probably rhetorically) that perhaps we need to abandon the idea entirely, because it is not working (for very large projects).

Re: Software Estimation Is a Losing Game (2014)

#24

Post by kzhahou »

wai1234 wrote: post #21
kzhahou wrote: post #8

I can estimate some tasks very accurately. I know that adding this new flag to my system will take a day. Other tasks I can accurately say I don't know how long they'll take. This new feature is... a couple of weeks? This new application is... a few months? I can roughly guess (estimate!) but there's a wide certainty margin. That uncertainty is never built into the mathematical model used by project managers, which i…

So, small tasks you CAN estimate, large ones not so much. Perhaps the technique to use is right in front of you: decomposition.

I can try to decompose a ~2-month task into one-day tasks, and still not improve my overall confidence level.

Re: Software Estimation Is a Losing Game (2014)

#25

Post by ThomPete »

roel_v wrote: post #7

Pardon my French, but it's a load of bollocks. Sure, I hate estimating and I'm bad at it, but I've worked with many others who were better than me at it and did consistently deliver what promised, when they promised it. And yes I'd much rather just sit and contemplate and re-re-rework 'the design' and be all-important about 'it's done when it's done' - but I fully well understand that any customer will just fire me a…

There is a huge difference between building a bridge and building a piece of software.

The complexity is just many many times bigger when it comes to software projects. With bridges it's actually fairly straight forward and the budgets are often of a completely different scale.

Re: Software Estimation Is a Losing Game (2014)

#26

Post by DonaldFisk »

There are Mathematical Limits to Software Estimation: http://scribblethink.org/Work/kcsest.pdf, http://scribblethink.org/Work/Softestim/softestim.html

In general, unless you've done something very similar before, estimation can't be done accurately. Your manager should know and accept this.

The best you can do is probably this: Repeatedly split the project into tasks, estimate the time it will take for each, until the next task takes several hours, and then do the next task. Keep track of estimates and actual times spent. Your manager should ask you to do this and keep it updated. Joel Spolsky wrote something similar here: http://www.joelonsoftware.com/articles/fog0000000245.html (I'm sure I read similar advice elsewhere, but can no longer find it.)

It should go without saying that you should include unit testing, code review, debugging, etc. in your estimates. And, of course, making and updating the time estimates.

The project, when "complete", will still usually require maintenance, so work on the project only stops when the software is no longer used.

You should never be given deadlines, as you won't know in advance what problems you might encounter, and the quality of your work (and probably your health) will suffer. This will result in a build up of technical debt, increasing maintenance costs.

It's well worth reading The Mythical Man-Month, especially if you're managing a project, or working with others on the same project.

Re: Software Estimation Is a Losing Game (2014)

#27

Post by sheepmullet »

wai1234 wrote: post #19

I have to laugh when I see these posts. So, software development is a special activity that should not be constrained by budgets or deadlines (or estimates)? Where do I sign up? There are so many strawmen here I can't possibly address them all. If you can't provide a credible estimate for a piece of work, you either a) aren't very good, b) don't properly understand the work to be done, or c) perceive some aspect of t…

Most of the problems are organisational rather than with estimating per se.

If I'm doing prod support for three different products and build work for two products, then I'm naturally going to be juggling priorities. There are a lot of different and changing variables in the mix and it makes committing to deadlines very difficult.

If an organisation wants to isolate developers and have them work on only build work for a single product estimation becomes much more accurate. Of course most orgs would rather less accurate estimation instead.

Re: Software Estimation Is a Losing Game (2014)

#28

Post by xacaxulu »

DonaldFisk wrote: post #26

There are Mathematical Limits to Software Estimation: http://scribblethink.org/Work/kcsest.pdf , http://scribblethink.org/Work/Softestim/softestim.html In general, unless you've done something very similar before, estimation can't be done accurately. Your manager should know and accept this. The best you can do is probably this: Repeatedly split the project into tasks, estimate the time it will take for each, until t…

The Mythical Man-Month is REQUIRED reading for anyone who might ever come close to estimating a software project in any setting. +++++1

Re: Software Estimation Is a Losing Game (2014)

#29

Post by jcadam »

If I'm ever asked for an estimate, it's after the project schedule has already been set in stone.

On my current project, I am the sole full-time developer. The requirements were gathered from the client without my involvement. The schedule was laid out without my input. Then the whole thing was dropped on me.

Re: Software Estimation Is a Losing Game (2014)

#30

Post by sheepmullet »

_xnmw wrote: post #23
wai1234 wrote: post #19

I have to laugh when I see these posts. So, software development is a special activity that should not be constrained by budgets or deadlines (or estimates)? Where do I sign up? There are so many strawmen here I can't possibly address them all. If you can't provide a credible estimate for a piece of work, you either a) aren't very good, b) don't properly understand the work to be done, or c) perceive some aspect of t…

"So, software development is a special activity that should not be constrained by budgets or deadlines (or estimates)?" Of course it is constrained, but how can you estimate it? Because "software development" is the continuous process of converting a real world idea into instructions that are so tiny and specific that a computer can understand them. Obviously you can't know in advance what those instructions are, or…

We can estimate better but it's often not worth it.

It makes sense when there is a large cost to not meeting a deadline. Or when it's difficult to change scope.

Post reply on HN