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

291–300 of 318 posts

Re: Software effort estimation is mostly fake research

#291

Post by xpe »

RicoElectrico wrote: post #94
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…

We should not conflate quality with value. [1] [1] https://moznainaczej.com.pl/Download/Teal%20Doctrine/A.Blikl... (13.10 Quality and value)

Welcome to Hacker News!

From your link:

> The more the product promises the customer, the more luxurious it is; the greater the extent to which these promises are fulfilled, the better the product’s quality.

While this is an interesting way of thinking about it, I find personally it to be both non-standard and not useful.

I'm generally not inclined to force or coin a definition of a concept that is intrinsically messy. Instead, I think it is better to take almost an anthropological view: unpack what different people and cultures mean by a word.

With this in mind, I recommend the following article from MIT's business school, because it embraces the vagueness and complexity of quality:

https://sloanreview.mit.edu/article/what-does-product-qualit...

Re: Software effort estimation is mostly fake research

#292

Post by rightbyte »

toolslive wrote: post #259

Hasn't anyone tried to replace time estimates with probabilities? (Like "There's a 80% chance we'll finish this today." ) You immediately start to understand why it can take so much longer than expected (You've rolled a dice before; I want a six... How long will it take)

I don't know if I am supposed to roll a 20 on a D20 or a 8 on a D8 to begin with.

Time estimation on a macro or micro level is just educated feelings.

The thing I notice with people that are forced to estimate time and have nagging managers is that they start to report time according to how much the task was estimated to, to make the burndown chart nice.

I.e. if one task is finished early a late running one gets the hours giving the illusion of getting better at estimating. I think Joel's estimation method for Frogbugz had the same fate linked in somewhere above.

Re: Software effort estimation is mostly fake research

#293

Post by commandlinefan »

a_wild_dandan wrote: post #58
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…

You've perfectly nailed the fundamental issue here. For many software projects, you simply cannot make meaningful granular estimations for parts of them. It doesn't matter how many story-point poker sessions you hold. Some software work cannot be reduced to a positive integer. In our business scopes creep, bugs plague us, and myriad issues make precise estimations pointless. It's engineering Numberwang. I get that fo…

> Some software work cannot be reduced to a positive integer

I'd take that a step further: if software work can be reduced to a positive integer, you're doing it wrong.

Re: Software effort estimation is mostly fake research

#294

Post by garethrowlands »

galaxyLogic wrote: post #246
TeMPOraL wrote: post #178

Earlier quoted context omitted.

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.

Programming is isomorphic to theorem proving (according to Curry-Howard). Therefore trying to estimate a software project is a bit like trying to estimate how long it will take to prove a new theorem in mathematics, assuming you would know which exact theorem you want to prove.

Er, isn't it just getting your program to typecheck that's equivalent to proving the theorem (by construction)?

I tend to find this isn't the main consumer of my software budget :-)

Re: Software effort estimation is mostly fake research

#295

Post by commandlinefan »

perl4ever wrote: post #199

I had access to information about historical projects, so I compared the actual amount of time taken to the estimated time at the beginning, for every software project in the history of my organization. I found that on average, things take twice as long as expected. So, I was like, now I know how to estimate any project. I figure out what seems reasonable based on known factors...and double it. A way to look at this…

Hofstatder's law: It always takes longer than you expect, even after accounting for Hofstatder's law.

Re: Software effort estimation is mostly fake research

#296

Post by commandlinefan »

tobyhinloopen wrote: post #168

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

> the application is thoroughly specced. You might need WEEKS for this

More weeks than it will end up taking to build the finished product, in fact.

Re: Software effort estimation is mostly fake research

#297

Post by imtringued »

x0x0 wrote: post #204
didibus wrote: post #119

Earlier quoted context omitted.

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

Inter-team dependencies. Marketing pushes. Customer commitments. New sales dependent on certain features. Building features to increase TAM. Partner commitments for interoperability / joint deployments. Even presentations of your roadmap to customers and prospects to get them bought into your vision of where the product is going. There's tons of things that require broadly knowing when X is going to be done beyond ca…

If you create low quality estimates willy nilly then don't be surprised that you will break them.

Re: Software effort estimation is mostly fake research

#298

Post by imtringued »

kevinmchugh wrote: post #250
cmroanirgo wrote: post #13

Earlier quoted context omitted.

The problem is knowing how fast they learn. For a n00b this is basically impossible, and takes cost monitoring to notice their rate of learning. For a person with the basics of the language that they'll be using, and a tiny bit of experience in the libraries they'll be using, things get easier. For everyone (n00b to senior) I would always recommend designing & breaking things down into no smaller 1/2 day blocks, wher…

It's very useful to break tasks down so instead of a month long "upgrade elasticsearch" story, there's dozens of day-or-less tasks to work on. Often it's not noticed how much effort goes in to creating these new smaller tasks. If you aren't extremely familiar with the targeted version of elasticsearch, you'll have to spend significant amounts of time investigating, planning, and writing. You can get very high accurac…

That means the business is taking safe bets. Depending on the industry this makes a lot of sense. If you are in a small business this probably won't help you.

Re: Software effort estimation is mostly fake research

#299

Post by JamesBarney »

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.

Yeah I've had a couple of managers try this. I always tell them my estimate is how long I think it will take take. But if he believes that estimate is incorrect he's welcome to modify it as he sees fit. (Over e-mail of course).

Sometimes they'll modify it, sometimes they won't but at least I won't have to argue about it or get in a situation later where suddenly they pretend like their estimate is my estimate.

Re: Software effort estimation is mostly fake research

#300

Post by JamesBarney »

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 don't really understand what type of environment you're talking about.

Some parts seems to hint the devs are an outside consulting shop, and some parts hint that the devs are on an internal team.

Most internal teams can blow through dev deadlines over and over again for years without any real repercussions. And while outside dev shops can't blow through estimates like internal teams the individual devs usually can unless they're in a leadership role.

Post reply on HN