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

11–20 of 50 posts

Re: Software Estimation Is a Losing Game (2014)

#11

Post by Nyetan »

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…

Actually, that's an excellent point -- how do buildings/bridges/etc. actually get built? I mean, laugh if you will, but can you not think of any examples of construction projects that straight up ran out of money and had to halt? Or that became enormous money and time sinks, inching their way but never-quite-making it to completion?

As I understand it (still pretty new to the industry), we're supposed to give realistic estimates for a product's completion, considering that 1. requirements are always incomplete and 2. unexpected complications will always arise. 'Done' is a moving target, and part of its estimation is ensuring the product is deliverable at every stage (with varying degrees of completeness), regardless of whether how many times everything goes pear shaped.

Re: Software Estimation Is a Losing Game (2014)

#13

Post by jacques_chester »

kzhahou wrote: post #10
jacques_chester wrote: post #9

Earlier quoted context omitted.

> That uncertainty is never built into the mathematical model used by project managers It depends on the project manager. The PERT estimation technique was based on giving a 3-part range estimate for broken-down tasks. These are then rolled up with a simple formula. In the PERT method independence is handled by creating explicit links between tasks, which leads to the concept of the critical path. Nobody does these.…

Thanks. Yeah, there's a fairly large number of formal management techniques, but like you said, they're very rarely used. PERT: https://en.wikipedia.org/wiki/Program_evaluation_and_review_... Barry Boehm's recent work: http://www.amazon.com/Incremental-Commitment-Spiral-Model-Pr...

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 a story, I like to ensure that we engineers say aloud what assumptions we're pointing on ("Bootstrap will make responsive mobile almost free") and then a quick low-detail breakdown of expected tasks ("new page, new RESTful endpoint, new model code").

I find that the latter, in particular, makes a big difference in how pointing goes.

[1] http://confidest.com

Re: Software Estimation Is a Losing Game (2014)

#14

Post by pnathan »

Nyetan wrote: post #11
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…

Actually, that's an excellent point -- how do buildings/bridges/etc. actually get built? I mean, laugh if you will, but can you not think of any examples of construction projects that straight up ran out of money and had to halt? Or that became enormous money and time sinks, inching their way but never-quite-making it to completion? As I understand it (still pretty new to the industry), we're supposed to give realist…

https://en.wikipedia.org/wiki/Bertha_(tunnel_boring_machine)

Seattle's current pear-shaped project. Check out the missed estimates!

Re: Software Estimation Is a Losing Game (2014)

#15

Post by tikhonj »

Nyetan wrote: post #11
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…

Actually, that's an excellent point -- how do buildings/bridges/etc. actually get built? I mean, laugh if you will, but can you not think of any examples of construction projects that straight up ran out of money and had to halt? Or that became enormous money and time sinks, inching their way but never-quite-making it to completion? As I understand it (still pretty new to the industry), we're supposed to give realist…

Sure. Developments get abandoned all the time, either because they run out of time and money or because economic conditions change. One I was reading about recent is the Fontainbleu Resort in Las Vegas[1]—the second-tallest building on the Strip and unfinished.

And even more developments end up hilariously past their budget on both time and money. "Megaprojects" like the Big Dig[2] are common examples of this.

These are the failures big enough to be notable. I'm sure there are far more smaller, less interesting but more indicative failed projects as well.

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

[2]: https://en.wikipedia.org/wiki/Big_Dig

Re: Software Estimation Is a Losing Game (2014)

#16

Post by AnimalMuppet »

oldmanjay wrote: post #5
knieveltech wrote: post #4

Earlier quoted context omitted.

Creativity and joy are fantastic qualities that are difficult to quantify on an accountant's spreadsheet. Clients have to be able to budget sufficiently for project work, and the only way they can do that is with an estimate. This is how business is done. "Uh..we'll send you a bill when we're done for...like...whatever it costs. I guess?" Isn't going to go over well when responding to a potential clients RFP.

Of course, given the historical fact that traditional project management doesn't work and the estimates are a farce, why should we happily continue doing this cargo cult uselessness?

They're not useless. Except sometimes they are.

I have to give estimates all the time. They're estimates, but they're in the ballpark.

But recently, I had to give an estimate for porting some software to a new environment. I knew it was going to present me with a bunch of obstacles, and I didn't know what the obstacles were, or how long each one would take. I didn't even know how many obstacles there would be.

I didn't want to give an estimate for that. They made me give them one anyway. I did, but I knew that no reliance whatsoever could be placed on the estimate. Whereas other tasks, estimates were close to "bet the company on it" solid.

Re: Software Estimation Is a Losing Game (2014)

#17

Post by thoman23 »

One of the comments on the original article nails it. The real problem is conflating "estimates" with "deadlines" or "commitments". You see it with the casual replacement of "story estimating" with "story sizing" in our language. "Sizing" implies a degree of certainty that may not be there.

Estimating is most definitely useful. But you have to fight every step of the way to keep an estimate from becoming a "promise". Promises that can't be kept are not good for any of the parties involved and lead to things like developer burnout, poor quality, technical debt, surreptitiously reduced scope, lack of trust...it goes on and on.

Re: Software Estimation Is a Losing Game (2014)

#18

Post by Nyetan »

tikhonj wrote: post #15
Nyetan wrote: post #11

Earlier quoted context omitted.

Actually, that's an excellent point -- how do buildings/bridges/etc. actually get built? I mean, laugh if you will, but can you not think of any examples of construction projects that straight up ran out of money and had to halt? Or that became enormous money and time sinks, inching their way but never-quite-making it to completion? As I understand it (still pretty new to the industry), we're supposed to give realist…

Sure. Developments get abandoned all the time, either because they run out of time and money or because economic conditions change. One I was reading about recent is the Fontainbleu Resort in Las Vegas[1]—the second-tallest building on the Strip and unfinished. And even more developments end up hilariously past their budget on both time and money. "Megaprojects" like the Big Dig[2] are common examples of this. These…

It was more of a rhetorical question, with the remaining literalness directed at the OP :) but yeah, those are fantastic examples! The Berlin Brandenburg [1] was what came to mind immediately, but you're absolutely right that history is like to be littered with other dead developments.

[1]: http://www.bloomberg.com/news/features/2015-07-23/how-berlin...

Re: Software Estimation Is a Losing Game (2014)

#19

Post by wai1234 »

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 the job that is unknowable to you (through lack of experience or other novelty). Fixing each of these is up to you. 'a' is obvious (you either work hard to get better or find something else to do). 'b' means you need to ask more questions that allow you to sufficiently complete your understanding of the problem so an estimate is possible. 'c' means you need to isolate the novelty and explain that this part of the problem is new to you and you are not qualified to provide an estimate. Perhaps someone else can provide that insight or you can define an initial activity designed to help you better understand the novel problem until you can estimate the remaining work. NO area of engineering is so cut and dried that estimation is easy.

What IS common is a combination of poorly defined projects and a profound lack of self-awareness. By all means, push back against poorly defined projects ("I can't estimate the work until you tell me what it is."). Lack of self-awareness is squarely in YOUR lap ("I don't understand why it always takes longer than I thought it would..." Well, duh, maybe you should consider that reality for what it is and account for it next time).

Estimating work and committing to those estimates is what a professional does. Deal with it. If estimates are imposed on you that you do not agree with, that has nothing to do with the virtue of estimation. That's a social problem, not a technical one.

Re: Software Estimation Is a Losing Game (2014)

#20

Post by cpitman »

jacques_chester wrote: post #13
kzhahou wrote: post #10

Earlier quoted context omitted.

Thanks. Yeah, there's a fairly large number of formal management techniques, but like you said, they're very rarely used. PERT: https://en.wikipedia.org/wiki/Program_evaluation_and_review_... Barry Boehm's recent work: http://www.amazon.com/Incremental-Commitment-Spiral-Model-Pr...

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 break down of how long each task or group of tasks will take so that they can negotiate down the estimate, not understanding that the total estimate is not a simple sum of each task. I'd love to hear better ways of explaining/using these sorts of estimates.

The first time was my fault: I left the columns that had intermediate values visible. One of those was the variance in each estimate, which is just the Std Dev squared. The numbers were big. No one could stop talking about how big the numbers were. No one knew what a variance was, nor appreciated that it was just the number in the previous column, multiplied by itself. Learned the very important lesson that you hide all your work, no one gets it.

Post reply on HN