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

Software effort estimation is mostly fake research

shape-of-code.coding-guidelines.com

Post reply on HN
Print view View original

261–270 of 318 posts

Re: Software effort estimation is mostly fake research

#261

Post by tilolebo »

eru wrote: post #252
dkarl wrote: post #127

Earlier quoted context omitted.

> Even houses always go over time and money and that is fairly straight forward. This is an incredibly important point. I was "raised" in commercial software at a time when there was a lot of condescension internally towards ourselves as an industry because we couldn't do estimation and planning, and building was the favorite comparison. A $100 million building couldn't run late or over budget. That would be unimagin…

From what I've heard, in construction most of the delays happen with the foundations. Everything that's below the ground is hard to predict, because you seldom know exactly what's in the ground. Once your construction has progressed above ground, it's somewhat more predictable. (But delays are still possible.)

There's also the problem of of a company working on multiple construction sites in parallel.

In software engineering, this also happens of course, especially if you develop in house. And you also need to factor in the maintenance, as it's usually performed by the same team.

Re: Software effort estimation is mostly fake research

#262

Post by amadvance »

eru wrote: post #252
dkarl wrote: post #127

Earlier quoted context omitted.

> Even houses always go over time and money and that is fairly straight forward. This is an incredibly important point. I was "raised" in commercial software at a time when there was a lot of condescension internally towards ourselves as an industry because we couldn't do estimation and planning, and building was the favorite comparison. A $100 million building couldn't run late or over budget. That would be unimagin…

From what I've heard, in construction most of the delays happen with the foundations. Everything that's below the ground is hard to predict, because you seldom know exactly what's in the ground. Once your construction has progressed above ground, it's somewhat more predictable. (But delays are still possible.)

I think that adding a feature to an existing software product is more like adding a new floor to an existing house.

Re: Software effort estimation is mostly fake research

#263

Post by reallydontask »

dkarl wrote: post #127
snarf21 wrote: post #98

Earlier quoted context omitted.

The issue is that you are being asked to estimate something that has never been done before. Even houses always go over time and money and that is fairly straight forward. These days, I only give estimates in terms of units but without numbers. Hours, days, weeks, months, quarters or years. Some relatively small number of those units. If you want a quote it will take an extra 1/4 of the estimate worth of time for an…

> Even houses always go over time and money and that is fairly straight forward. This is an incredibly important point. I was "raised" in commercial software at a time when there was a lot of condescension internally towards ourselves as an industry because we couldn't do estimation and planning, and building was the favorite comparison. A $100 million building couldn't run late or over budget. That would be unimagin…

Oh man, this hits home so much.

I used to lead a software department in a small company that sold software to, mainly, the construction industry, so the go to comparison was building houses, which according to my boss, were always on time and on budget, unlike software.

The funniest thing about it was that our software was used by huge projects: Hinkley Points C, HS2, etc ... which obviously have an great track record of being on time and on budget ಠ_ಠ

Re: Software effort estimation is mostly fake research

#264

Post by Gene_Parmesan »

tikhonj wrote: post #174
lixtra wrote: post #143

Earlier quoted context omitted.

Typically there are many dimensions to a solution, the negotiation can be about trading one dimension for another. - does it have to be instant or can we run it as a batch - maybe it’s enough to have this tool in English only Etc.

Negotiating scope is a different mindset than negotiating estimates . Even better would be making sure the team understands both the real goal they're trying to achieve and how time plays into it, letting the team make scope trade-offs like that as they go along.

All discussions about estimates are really just discussions about scope. I try to make that as clear as possible when I'm talking about time estimates. There is no 'negotiating' estimates. If someone is being a little pushy with trying to get a shorter estimate, I will always just rephrase it as a trade-off. 'Doing it in fewer than X months would mean dumping X feature/walking back on Y commitment,' whatever the case may be.

I think in general these conversations always go better when you make the other person feel like they have a choice. Really, in today's corporate world everyone is playing CYA at all times. The person trying to bring down the estimate is probably doing so because they are anticipating what their boss will say. By listing potential trade-offs for them, I'm helping them by giving them fodder for that talk that they'll be facing, and they'll be able to give their boss a choice.

You always get better reactions out of people when they have choices, rather than just presenting a stone wall to them. Having said that, some times the person will really just keep being pushy, and then fortitude is necessary. If you are someone who has trouble definitively saying 'no' when it's required, you're doing your team a disservice by being the person giving estimates. You really need to never slip with this; all it takes is for you to one time cave and say, "okay, maybe we can try to shave a week off" and now that person knows that your estimates are negotiable.

If you consistently phrase them as facts rather than bids (like the sort of estimate a contractor gives you for a house), you'll get better results.

Re: Software effort estimation is mostly fake research

#265

Post by Aldipower »

fphilipe wrote: post #254
Aldipower wrote: post #4

I am 20 years in development business now. This simple rule of thumb works for me and the team: (Your honest and concise estimation) * 3 There are just to many unknowns you cannot foresee. Software development is complex.

Great anecdote posted here a few years ago: https://www.quora.com/Why-are-software-development-task-esti...

Great read!! :D

Re: Software effort estimation is mostly fake research

#266

Post by ohthehugemanate »

didibus wrote: post #82

The issue with estimates are expectations. While nobody acknowledges it, you're not actually asked for an estimate, you're being asked for a quote. The difference is when you're asked for a quote, you're asked how much you will be charging, with the expectations that you'll be willing to eat into your own margins to give a lower quote. That's why it's a negotiation, where you negotiate how much extra effort, time and…

This is only true when estimates are in concrete units, the way we did it in the 80s and 90s. Unfortunately that still impacts contract structure today and it's hard to change on that level.

TFA is talking about estimates inside projects, which are not time based anymore in any environment that cares about the problems you laid out.

Personally I offer my customers to either pay by the week, or pay by extremely fixed scope with a 3 month definition period up front and a 50% buffer above the estimate. I stress that paying by the sprint lets them change objectives at any time, gives them an always-current report of how much "effort budget" they have left to work with, and guarantees they only pay for what they use. That felt like a risky move the first time I did it, but I never lost any business over it.

Re: Software effort estimation is mostly fake research

#267

Post by zyber »

ohthehugemanate wrote: post #266
didibus wrote: post #82

The issue with estimates are expectations. While nobody acknowledges it, you're not actually asked for an estimate, you're being asked for a quote. The difference is when you're asked for a quote, you're asked how much you will be charging, with the expectations that you'll be willing to eat into your own margins to give a lower quote. That's why it's a negotiation, where you negotiate how much extra effort, time and…

This is only true when estimates are in concrete units, the way we did it in the 80s and 90s. Unfortunately that still impacts contract structure today and it's hard to change on that level. TFA is talking about estimates inside projects, which are not time based anymore in any environment that cares about the problems you laid out. Personally I offer my customers to either pay by the week, or pay by extremely fixed…

I think that everyone still converts what-ever-unit used to time. For example, from one of my earlier jobs, we had "T-shirt"-size units, ranging from XS to XL. It took two weeks after introducing them until someone figured out that XS is two hours, so in a sprint you should be able to do $SPRINT_DURATION / 2 XS tasks. And then the person figured that S was equal to, say 4 hours and so on and we were back on square one. But we didn't estimate in concrete time units. /s

Re: Software effort estimation is mostly fake research

#268

Post by mathw »

amadvance wrote: post #262
eru wrote: post #252

Earlier quoted context omitted.

From what I've heard, in construction most of the delays happen with the foundations. Everything that's below the ground is hard to predict, because you seldom know exactly what's in the ground. Once your construction has progressed above ground, it's somewhat more predictable. (But delays are still possible.)

I think that adding a feature to an existing software product is more like adding a new floor to an existing house.

Sometimes it's like adding a new floor to an existing house in between two of the existing floors without any of the occupants noticing.

Re: Software effort estimation is mostly fake research

#269

Post by stiray »

didibus wrote: post #82

The issue with estimates are expectations. While nobody acknowledges it, you're not actually asked for an estimate, you're being asked for a quote. The difference is when you're asked for a quote, you're asked how much you will be charging, with the expectations that you'll be willing to eat into your own margins to give a lower quote. That's why it's a negotiation, where you negotiate how much extra effort, time and…

I have noticed this article during the "Parkinson's law of triviality"[1] meeting (within phase where technical guys are typically silent) and almost started laughing when someone asked about "over the thumb effort estimates" (that are always becoming carved into rock deadlines).

It really made my day :)

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

Re: Software effort estimation is mostly fake research

#270

Post by koonsolo »

sporkland wrote: post #186
koonsolo wrote: post #136

Earlier quoted context omitted.

I once had a manager that thought he could negotiate estimates. That is like negotiating with the weatherman about the weather. Sure, maybe in the end you can convince them it will be finished sooner. But the fact is that it really doesn't change reality.

I hate to sound cynical, but it can change reality if he were to use the estimate to extort overtime out of the team by citing their own estimates. I don't think it works out medium to long term, but could help him short term with the right teams. I assume they were also hiring for pliability/submissiveness. The big cost tends to be software quality as it is less visible/harder to measure than dates and scope.

In practice, the lower you can get the estimate, the more it will shoot back in your face.

I can say that this company had the worst planning I have ever seen, with some project not being able to finish at all.

Post reply on HN