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

121–130 of 318 posts

Re: Software effort estimation is mostly fake research

#121

Post by jeena »

didibus wrote: post #107
quickthrower2 wrote: post #90

Earlier quoted context omitted.

That is the degenerate scenario, but it’s not always true. Often I see this haggling down of estimates and then microagression if estimates are not met but no need to work for free to make up for it. And I’ve also seen wise use of estimation but that is rarer!

> And I’ve also seen wise use of estimation but that is rarer I've got a question for you here, what is a wise use of estimation? What problems are estimates the ideal solution for? In the context of software development? I can think of only two: planning headcount and priorities (aka planning the order in which you do things). When you focus on those problems, you realize there's no need for an accurate estimate. Al…

Who cares when it's done? Often there are external deadlines like a start of production of a car for example which can not realistically be moved because too much planning would need to be redone and too much disruption would cause so much overhead that it could break a company.

Also when price and time are fixed, there is only one thing left for negotiation and it is the amount of features being delivered. Sometimes people have a hard time to cope with it but if you do it correctly it's a great thing for everyone. The most important features could be delivered early and the closer to the deadline the non critical features can be implemented which are nice to have but won't break the product if they're not in place. That's a great way to bring as much value as possible without breaking anyone.

Re: Software effort estimation is mostly fake research

#122

Post by _y5hn »

didibus wrote: post #107
quickthrower2 wrote: post #90

Earlier quoted context omitted.

That is the degenerate scenario, but it’s not always true. Often I see this haggling down of estimates and then microagression if estimates are not met but no need to work for free to make up for it. And I’ve also seen wise use of estimation but that is rarer!

> And I’ve also seen wise use of estimation but that is rarer I've got a question for you here, what is a wise use of estimation? What problems are estimates the ideal solution for? In the context of software development? I can think of only two: planning headcount and priorities (aka planning the order in which you do things). When you focus on those problems, you realize there's no need for an accurate estimate. Al…

Wise use of estimation is projection. You don't need to do much more than count stories. It would be honest and without agenda.

I've never seen it either.

Re: Software effort estimation is mostly fake research

#123

Post by xyzelement »

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 never experienced the dynamic you are talking about. Sounds like your workplace is terrible.

I've almost always had business partners that were just that - partners - invested in the product and the team long term. I am the same way now that I am "the business."

Estimation is a useful forcing exercise for thinking through what something takes, identifying risks and hard parts and deciding upfront what to do about them.

It also becomes a good measure of people's integrity - what they do once it's apparent the estimate is off. 100% of the time, when engineering came back saying "we underestimated X, it's much harder" - it was totally fine.

Re: Software effort estimation is mostly fake research

#124

Post by samsk »

My bulletproof formula for doing estimations in corporate environments:

InternalEstimation = estimate the work as truly as possible (ie. in MD) ExternalEstimation = double the value of InternalEstimation, and increase units by one order

Example: 1 day (MD) = 2 weeks 2 weeks = 4 months

Re: Software effort estimation is mostly fake research

#125

Post by kylecordes »

Sometimes a request for an “estimate” is really a request for a promise, quotation, a guarantee that something will be delivered by X time or cost.

It's easy to detect this:

Gently begin a discussion of how much uncertainty is tolerable, do they want to know the number we are 50% likely to hit? 80%?

If you get emotional pushback to discussing uncertainty, they are looking for a promise.

Re: Software effort estimation is mostly fake research

#126

Post by kylecordes »

crispyambulance wrote: post #85
jakubp wrote: post #2

If someone can conclusively teach inexperienced programmers good approach to estimates (methodology) + help embed this into sales process of a software house-type company, I know some folks who'd love to have this :) My own experience has been this: people make estimates, client has expectations based on some variant of those, and something later happens but so much change is introduced during the actual software dev…

> ...nobody cares! > Nobody learns. > It's insane. Estimation is really hard, especially if you're dealing with new challenges, new people, and new expectations. Throwing moving targets (unplanned changes) into the mix, as you noticed, makes estimation even more difficult. The thing is, it very rarely is the case that a wrong estimate will sink a project. Things get delivered late all the time. No one dies. Most stak…

Failure is a tricky thing.

There is a story that Microsoft Word was a staggering failure in terms of actual time and cost to implement versus its estimates.

It then went on to be among the most lucrative ($ billions) pieces of software ever created.

Was Microsoft Word a failure?

Re: Software effort estimation is mostly fake research

#127

Post by dkarl »

snarf21 wrote: post #98
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…

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 unimaginable, and it doesn't happen because those people are too serious and professional to let it happen, not like us unserious, immature software doofuses. Turns out that was a complete lie, but at one time it warped the profession, because it made people believe the answers already existed, right around the corner, something you would figure out pretty soon just like last year you didn't know regular expressions and now you did.

The problem with that was that when somebody walked in with a button-down shirt, oozing confidence and saying they knew exactly how to consistently deliver software on time and bug-free, those people weren't laughed out of the room. Elaborate heavyweight processes, and their "lightweight" (hah!) cousins, could sell themselves as proven, established solutions. We could believe that bullshit because we had been fed the lie that other industries had conquered these problems.

Re: Software effort estimation is mostly fake research

#128

Post by yibg »

To me the difficulty of estimating software projects isn't about estimating the time / effort to build the thing. The biggest uncertainty is trying to estimate what it is we're trying to build in the first place. i.e. the details of the spec. Often times where I've seen estimates really off is when the scope changes, or more details are discovered etc.

To borrow the usual building a house analogy, if during software estimation we're actually given how many rooms, how many floors, where are the doors and windows etc, then I think estimates will be a hell of a lot more accurate. Instead, what we typically get is, build a house that can be used by the family of 4, and we'll discover exactly what the family wants as we build.

Re: Software effort estimation is mostly fake research

#129

Post by didibus »

corry wrote: post #115
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…

'I really wish we would treat sales people the same way. "How much money is this contract for? What date will it be signed?"'. In well-run sales teams, that is exactly what happens. There is a constant move towards more accuracy and tightness in forecasting. In poorly run sales teams, the reps basically set their owns quotas (padded, of course, to mitigate against massive uncertainty) and then are very imprecise at m…

I think you're talking about goals, which isn't the same as estimates.

A well run sales team, like a well run dev team do benefit from goals. Like increase X by Y. That's because it can guide your decision process of what you'll spend your time on and what you won't. It can also push for focused innovation around a particular area.

But I think OP meant what if you asked the sales team: How much time will it take you to close the deal with X? Would they be able to estimate that? Which is different from asking them: "Try and close X Y% faster than it took us to close Z last time." The former would be asking for an estimate, the latter would be setting a goal.

Re: Software effort estimation is mostly fake research

#130

Post by mekoka »

ChrisMarshallNY wrote: post #34

I find this amusing. Know how much a Honda Accord costs? About 25 Grand. Know how much a Mercedes S450 costs? About three times as much. They are both great cars, that will be rewarding to own. The Mercedes doesn't have 3 times more parts, but it probably took four times longer to make, and they paid the folks that make it, a lot more than the Honda. It's actually, probably better "bang for the buck," although it won…

> It's actually, probably better "bang for the buck," although it won't seem like it, on the surface.

A car's primary function is to move its passengers from point A to point B, safely and timely. Both cars do this very well, but the Mercedes will probably be costlier over their respective lifetime (fuel, parts, service).

The only way for it to be a better bang for buck would be to turn its secondary functions (comfort, prestige, signalling) into a primary tool. For instance, if a broker or salesperson finds that owning the car gives them the added confidence to project the image they want during negotiations and thus contributes to their overall success, then it becomes a worthy investment.

Post reply on HN