Software effort estimation is mostly fake research • Hacker News Board

Re: Software effort estimation is mostly fake research

#161

Post by chasd00 » Mon, Jan 18, 2021, 10:40 PM UTC

TehShrike wrote: post #73

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.

I multiply by 4. Specifically, giving estimates on when features will be deployed/usable by end users.

yes, going from identification of the bug/idea to the solution in end users hands is a lot different than just the coding estimate. On teams with multiple levels of management both engineering side and customer side the actual code required to fix/implement the solution is such a small part of the overall effort you could, ironically, consider it immaterial.

Re: Software effort estimation is mostly fake research

#162

Post by alisonkisk » Mon, Jan 18, 2021, 10:43 PM UTC

trimbo wrote: post #76

durandal1 wrote: post #21

Earlier quoted context omitted.

Apple executes massive feature releases on a yearly waterfall-like schedule across hundreds of teams. It requires honesty, transparency, strong leadership (ruthless prioritization), strong cross-team goodwill, strong cross-team collaboration as well as a solid body of experienced top-tier engineers. Other than that there's no magic. While there are teams within apple that does scrum/agile, none of the core OS/framewo…

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.

Re: Software effort estimation is mostly fake research

#163

Post by csours » Mon, Jan 18, 2021, 10:44 PM UTC

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…

> "There is very little invention going on."

If you said there is very little fundamental research going on, I would agree with you; but even putting together building blocks in a new way is invention. If you look at patents (arguably a unit of invention), most of them don't have fundamentally new building blocks, just existing blocks put together in new ways.

Re: Software effort estimation is mostly fake research

#164

Post by elwell » Mon, Jan 18, 2021, 10:46 PM UTC

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.

That's a recursive definition (estimate * 3) = ((estimate * 3) * 3) = (((estimate * 3) * 3) * 3)... But if you do that for a few years, "your honest and concise estimation" starts to grow because you've seen how it usually takes longer than expected, and your coefficient can approach 1.

Re: Software effort estimation is mostly fake research

#165

Post by einpoklum » Mon, Jan 18, 2021, 10:50 PM 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…

> These days, I only give estimates in terms of units but without numbers. Hours, days, weeks, months, quarters or years.

Then you must be either an independent contractor or have some magical source of job security. I couldn't get away with this kind of estimate.

Re: Software effort estimation is mostly fake research

#166

Post by mcguire » Mon, Jan 18, 2021, 10:50 PM UTC

Would software effort estimation work better if software developers were held to fixed-price bids?

Re: Software effort estimation is mostly fake research

#167

Post by didibus » Mon, Jan 18, 2021, 10:54 PM UTC

xyzelement wrote: post #132

didibus wrote: post #129

Earlier quoted context omitted.

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…

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?

Re: Software effort estimation is mostly fake research

#168

Post by tobyhinloopen » Mon, Jan 18, 2021, 10:57 PM UTC

I feel like I can get pretty good estimates on the following conditions:

- the application is thoroughly specced. You might need WEEKS for this. - all variables are taken care of. Stack is known, and you’ve experience with all parts involved. If you don’t, get familiar with the parts first. Again, might take weeks. - there is no implicit functionality. It is either explicit or not included. - there are clear boundaries and rules to prevent feature creep. - you cannot estimate an estimate - all designs and UX are final

Now the problem is, this estimate is really expensive, because it’s actual work. It takes about 10-25% of the total project time to estimate the project.

Re: Software effort estimation is mostly fake research

#169

Post by gugagore » Mon, Jan 18, 2021, 11:01 PM UTC

meheleventyone wrote: post #140

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…

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.

Re: Software effort estimation is mostly fake research

#170

Post by mwfunk » Mon, Jan 18, 2021, 11:06 PM UTC

daanlo wrote: post #134

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…

Software doesn‘t exist in a vacuum. The marketing team needs to know when the landing page / qr code (whatever) is implemented, because they need to plan their marketing budget. The customer care agent that gets shouted at because feature xyz is broken / not working as the customer expects, would like to give the customer an answer when it will be fixed. The customer care manager is also worried about her team member…

Agreed, marketing (and everyone, really) needs at least rough estimates. Software is notoriously hard to predict. As time goes on, estimates get updated as more is known about the problem and the org's ability to solve it. So, by definition the first estimate anyone makes at the beginning is the least reliable one, by a long shot, but it's something to start with that gets refined as time goes on.

I think where companies can get in trouble with software is when the initial rough estimate somehow gets blessed as the plan of record to cement in everyone else's critical path, and subsequent estimates are treated as engineering screwups rather than more informed predictions. I don't know what the solution is, because stuff like this can happen with everyone involved being super competent and having the best intentions. And sometimes there are engineering screwups, neither side is always blameless.

Power imbalances between organizations are where natural creative conflicts go bad. In a less healthy company, whichever org is on top politically tends to be blameless, whether it's fair or not, which ultimately hurts everyone's ability to do their best work because conflicts between orgs are less likely to be resolved based on what's best for the company or project as a whole. In ideal companies, orgs are balanced such that they can push back on each other for good reasons, but not for zero-sum, shit-rolling-downhill reasons. I'm pretty sure ideal companies only exist briefly or never though.