Software effort estimation is mostly fake research • Hacker News Board

Re: Software effort estimation is mostly fake research

#221

Post by lutorm » Tue, Jan 19, 2021, 2:14 AM UTC

didibus wrote: post #119

jeffreygoesto wrote: post #116

Earlier quoted context omitted.

Get something ready for Christmas business? Get a car on the road? Finish the cruise ship in time? ...

> In the context of software development? While your examples I'm not sure are super relevant from a software development context. I think you're pointing out that the estimate would help you decide when you need to start so you are done before the "real life events that needs the thing". Is that correct? Like for example I'm not sure it's useful to learn that no, you will not be ready for the Christmas event. Or no…

I haven't seen this issue arise very often in software

No? Maybe not if you're a software-only company. But for pretty much every hardware (a gadget, a car, a rocket, whatever), the software is part of it and it aint working until the software is.

If you don't want your product to be held shipping because the software isn't ready, you better have some way of estimating when it's going to get done so you can either trade features, personell, or even just knowing that there's no point rushing the hardware because it'll be done way before the code anyway.

Re: Software effort estimation is mostly fake research

#222

Post by ryandrake » Tue, Jan 19, 2021, 2:15 AM UTC

IanCal wrote: post #171

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.

I think this is a vital point. Estimates help narrow down what is important and what isn't. Maybe you want features x, y and z. If it takes a day then X is worthwhile, if it's going to take a month don't bother. Z must be done so if that's going to take a long time we need to drop y. One of the best product owners I've worked for would often ask for estimates and base plans and features from those. Some things would…

I remember an interview at a well known tech-ish company where the question started out as “Estimate this project” with a good description of the scope and team. After I said something like 4 months, interviewer said, “OK. The CEO says it needs to be done in 2 weeks. What now?”

I thought this was a basic project management question about trading off quality, scope, schedule, staffing, etc. and offered the usual suggestions of cutting scope (nope CEO demands entire scope), cutting quality (nope can’t compromise quality), increasing the team, contracting out, reprioritizing and realeasing P1s in 2 weeks (nope, nope, nope). Obviously I didn’t get the job.

Later I learned from an acquaintance inside the company that the right answer was probably “Work the team 24 hour days, nights and weekends, for 2weeks to deliver what the CEO wants. I think I dodged a bullet there.

Re: Software effort estimation is mostly fake research

#223

Post by pwillia7 » Tue, Jan 19, 2021, 2:17 AM UTC

didibus wrote: post #129

corry wrote: post #115

Earlier quoted context omitted.

'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…

Yes, it's like that. You have to move deals through many stages. There's expectations of timing into each stage in addition to quota. Most places will fire even senior sales people if they don't perform for a few quarters.

Re: Software effort estimation is mostly fake research

#224

Post by andi999 » Tue, Jan 19, 2021, 2:19 AM UTC

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…

At least for government projects the 'wrong' estimates are intentional. Admins always take the cheapest quote, so to earn money everything happening during construction has to be 'out of scope'. Like winter, or different soil layer than specified, or whatever.

Re: Software effort estimation is mostly fake research

#225

Post by sooheon » Tue, Jan 19, 2021, 2:19 AM UTC

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…

"$$$ closed at the end of the period" causes negative externalities at the expense of value delivered in the long run (overpromising, misleading, mispricing). This isn't unique to sales/engineering, I've heard of it playing out the same way in "factory" law firms where sales-lawyers and delivery-lawyers are separate.

Re: Software effort estimation is mostly fake research

#226

Post by valenterry » Tue, Jan 19, 2021, 2:20 AM UTC

perl4ever wrote: post #202

taeric wrote: post #89

My problem with this is all estimation is hard. Period. Quantitative discussions of something that has been done? Fairly easy, if still not accurate. Discussing something that hasn't been rehearsed before? You can really only discuss how long you are willing to work on it. Not how long it will take to get done. Fun examples. How long would it take you to clean out your fridge? How long would it take you to learn to p…

Estimation is hard if you are stuck in the mindset that you have to make a point estimate. It's not hard at all if you are willing to be (and are allowed to be) honest about the uncertainty of the inputs and calculate the uncertainty of the final result based on that. It's true that people may demand precision that you can't give them. But at the same time, you know something and it is simple to compute what you know…

This!

If you estimate, estimate a distribution.

Re: Software effort estimation is mostly fake research

#227

Post by ethbr0 » Tue, Jan 19, 2021, 2:27 AM UTC

TeMPOraL wrote: post #178

gugagore wrote: post #169

Earlier quoted context omitted.

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.

Also because planning gets you to make your desires explicit and to put them in a useful framework. Unexpected problems, disruptive as they may be, don't usually derail the whole plan. Some parts may need to be rethought, but others are still valid, and the whole thing keeps you focused.

There was a submission on this (in the annals of HN) where someone made the point that, more often than not and under normal project scenarios, unexpected problems usually do derail the entire software engineering plan.

The gist being: estimates are given with zero as a lower bound, and some upper bound. In reality, there is no upper bound. Software engineering can and does involve unexpected problems that would take infinite time to solve.

Ergo, project timelines are more accurately averaged between {min_time} and {infinite}, and, given that, remaining risk is the only true metric that should be reported. I.e. how far are we along in terms of project completed, such that we can say only x% of the project remains, and therefore that 1-x% did not explode.

Re: Software effort estimation is mostly fake research

#228

Post by antihero » Tue, Jan 19, 2021, 2:29 AM UTC

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.

Sounds like the type that thinks that if they blow enough smoke up your arse then you get things done quicker, and they look better. I hope they die out.

Re: Software effort estimation is mostly fake research

#229

Post by yarg » Tue, Jan 19, 2021, 2:38 AM UTC

danieltillett wrote: post #196

BurningFrog wrote: post #187

Earlier quoted context omitted.

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.

I used to be a non-technical manager “managing” a team of developers. I later (through circumstances) became a developer. Looking back at the games my team played with me I can see why many managers are cynical about the estimates they are given and attempt to negotiate.

I always overestimated because it was the only way that I could ever devote anytime at all to technical debt reduction.

Re: Software effort estimation is mostly fake research

#230

Post by franzwong » Tue, Jan 19, 2021, 2:40 AM UTC

In my previous company, we needed to put project code into timesheet for every activity. Of course, requirement gathering is also an activity. However, before you get the budget, you don't have the project code. Also, you can't get the budget before you have the estimate. It means I needed to give an estimate before I know what system I am going to build.