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

181–190 of 318 posts

Re: Software effort estimation is mostly fake research

#181

Post by saurik »

gugagore wrote: post #169
meheleventyone wrote: post #140

Earlier quoted context omitted.

It doesn’t even have to be a big construction project to hit budget and schedule issues. Rebuilding our house had us going right back to the drawing board having to get new plans drafted and approved. It worked out much better in the end but the unforeseen cost and time overrun was quite anxiety inducing at the time. But yeah the idea anyone has magically solved accurately predicting the future is completely bonkers.

I like to remember "plans are useless but planning is indispensable". The plan is useless because of the challenge of predicting the future. But the planning is useful because trying to predict the future gets you asking good questions.

What is then terrifying to me then is when I find myself working with people who manage to, by way of treating "estimates" as "quotes", make it so demoralizing to plan anything--as it will be "used against you" later (which they do even if they were adamant they wouldn't)--that everyone does everything they can to discourage and sabotage any attempt at planning, because planning is valuable :(.

Re: Software effort estimation is mostly fake research

#183

Post by TeMPOraL »

didibus wrote: post #160
_y5hn wrote: post #122

Earlier quoted context omitted.

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.

Yes exactly! When you ask someone for their estimate, you're getting a quote from them. When you actually want to predict the length of time something will take, you rely on historical data and create a projected forecast. It never involves asking somebody for their best guess. That's how every single "other thing" we predict is handled, so why is software done differently. Actually, I've seen some of these ideas bei…

Didn't Joel Spolsky implement it all the way back in the stone age... er, 2007[0]?

The idea is old. The problem is, in many software companies, none of the tasks look alike. So your past data is going to be somewhat dirty, particularly at team level. Perhaps as an individual, intimately familiar with the problems you encounter, being able to introspect your own thought process - perhaps you or me, we could learn to estimate better. Except the existing popular tooling absolutely sucks at facilitating that.

--

[0] - https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...

Re: Software effort estimation is mostly fake research

#184

Post by valenterry »

btbuildem wrote: post #109
csours wrote: post #10

"Estimates" are for things you've done before - like you can estimate building a house, because people have built houses before. The more like an existing house, the better you can estimate it. Software is invention and construction. The construction part is pretty easy to estimate. The invention part is ... very very hard. I'd like to say it's impossible. I'd like to see the software industry use a different word th…

I'd beg to differ. There is very little invention going on. Most software solutions tackle well-known problems, customized to a particular business need. Akin to building a house, but with specific owner requirements (three-car garage, etc). It gets a little complicated partly because of the industry's penchant for reinventing its tools on a rolling basis. In the trades, technology remains largely unchanged over deca…

> Most software solutions tackle well-known problems, customized to a particular business need. Akin to building a house, but with specific owner requirements (three-car garage, etc.).

Not really. The "building" part in software really is compiling and deploying your code. With CI/CD being set up, this takes a few minutes and requires almost no effort.

So what's left is not "building" the house but "designing" it. Unfortunately, the comparison you give fits more for buying a software and installing/configuring it. Then yes, this should be rather well estimatible, given that you have done it before.

But most software developers are not paid for that. They are paid to design a space station that has never existed before. Sure, they can use existing parts (libraries, frameworks) but it is still design in the sense that certain expectations are simply not possible. Or someone wants that the space station is connected to the other space station on another planet and we don't even know how the other space station looks like (it's built by another company). Who knows if it's even possible to connect them? And if not, the other space station might have to be adjusted to be connectable and this must be done by the other company. How long will that take? Who knows...

By the way, don't think about a space station like the ISS here. Please think about a space station like the star wars death star. Because that's the complexity of most software where estimates are desired and important.

And we are only talking about design, not building. The building part is easy - once we have designed it, we can actually copy it and have 100 of these exact space stations easily.

Re: Software effort estimation is mostly fake research

#185

Post by xyzelement »

didibus wrote: post #167
xyzelement wrote: post #132

Earlier quoted context omitted.

Sales team certainly understand the sales cycle and different velocities involved. Eg - two jobs we ago sold to finance playera from small hedge funds to huge asset managers to central banks and finance ministries. You could sell more small hedge funds by knocking on more doors but you understood that the big players took months and years to decide. And of course we always tried to hone the sales org and process to a…

Moving faster and increasing impact of deliveries, those are goals you can work towards, that do not involve needing to estimate anything. The question is: do you for every sale provide an ETA of when you think the sale will close, with projected key milestones along the way and their dates, all before even beginning engaging the would be customer?

// do you for every sale provide an ETA of when you think the sale will close, with projected key milestones along the way and their dates, all before even beginning engaging the would be customer?

No because that's kind of useless.

With software, the estimate is (or should be) part of the go-no-go decision for the project. "Oh, it's gonna take us 10 years to build this? Maybe we should reconsider"

Re: Software effort estimation is mostly fake research

#186

Post by sporkland »

koonsolo wrote: post #136
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 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.

Re: Software effort estimation is mostly fake research

#187

Post by BurningFrog »

koonsolo wrote: post #136
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 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.

You and I act like weathermen in this situation.

But plenty of engineers do estimate based on what they think they can get away with or other negotiable ways.

Re: Software effort estimation is mostly fake research

#188

Post by [deleted] »

koonsolo wrote: post #136
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 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.

[deleted]

Re: Software effort estimation is mostly fake research

#189

Post by sleepygardener »

alisonkisk wrote: post #162
trimbo wrote: post #76

Earlier quoted context omitted.

Have you noticed their declining OS release quality in recent years? I have, and I now wait 6 months to upgrade. The triangle is real[1]. Something's gotta give when a deadline can't move, and as we know from Brooks, software development speed doesn't increase linearly with more people. So it's primarily quality or scope that must suffer to hit a software deadline. [1] - https://en.wikipedia.org/wiki/Project_manageme…

People have been saying that since OS X first came out, and OS 9 was so buggy it had a famous cute bomb icon for when it crashed.

I'm using MacOs/OsX since Lion, and I can say that it was very stable (even on my Hackintosh) and I observed stability issues increasing with all the following versions (on real Apple HW) and I'm on the same ship as GP never upgrading to newer versions until at least 6 months pass.

Re: Software effort estimation is mostly fake research

#190

Post by ballenf »

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…

> at least there is a very objective measure ($$$ closed) at the end of the period.

That is far from an objective measure standing alone, unless every salesperson generates all their own leads and the distribution of potential leads is random.

But generally your more experienced members will get the bigger potential customers.

So now you're back at square one trying to judge their success in relation to the anticipated likelihood of their leads.

Post reply on HN