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

101–110 of 318 posts

Re: Software effort estimation is mostly fake research

#101

Post by mr_tristan »

mr_tristan wrote: post #86

I wish as much attention was paid to perform post mortems regularly then to only do estimation. You know, actually look at "hey, this is what we guessed and this is what actually happened". I've had to fight to actually hold post mortems, and every time I've done this, the manager ends up asking, "hey, can I share this?" So clearly, there's value, at least when we've done them. I'm amazed at how few places even perfo…

To tie this a bit more into the actual article: It might be even more accurate to just ask people in a post mortem for some feedback, instead of trying to build some data set based on estimates and SLOC. Like an exit poll.

Re: Software effort estimation is mostly fake research

#103

Post by KineticLensman »

jakubp wrote: post #20
csours wrote: post #14

Earlier quoted context omitted.

> "complete" means every single item the customer wants to see in the product, Ah, but the customer does not know everything they want, due to the fractal nature of reality. The closer you get to the end product, the more detail is resolved, and more work is added.

Oh man, thank you for the fractal nature of reality. That is the perfect term to describe what I saw about ever-changing requirements. No matter how closely you define something, things will always keep changing on all levels when closer to actually "delivering" / launching. Adding time, costs, confusion, frustration. Fractal, yes, that's it :)

> No matter how closely you define something, things will always keep changing on all levels when closer to actually "delivering" / launching

Xeno's paradox [0] doesn't apply here. Some projects do actually finish.

[0] https://en.wikipedia.org/wiki/Zeno%27s_paradoxes#Achilles_an...

Re: Software effort estimation is mostly fake research

#105

Post by 1337shadow »

cmroanirgo wrote: post #19
1337shadow wrote: post #9

Earlier quoted context omitted.

Make a complete list of things to develop in a spreadsheet, "complete" means every single item the customer wants to see in the product, not only every single button but also every single label, that should be definable by reading the project specs or mockups. I think "forgetting things" is the first big mistake leading to under estimations. Add an estimate that you multiply by three in front of each, ie. if the dev…

I forgot to add this to my other comment. Yes, a multiplier works wonders. (I typically added 30% to my own estimates, which covers all the little incidentals that trip you up, and coffee breaks). I've not been forced to work longer than an 8hr day since the 90's.

I thought your comment stating that time should be added for both research & design was actually a reasonable explanation for why I need the *3 multiplier!

Re: Software effort estimation is mostly fake research

#106

Post by composer »

1337shadow wrote: post #9
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…

Make a complete list of things to develop in a spreadsheet, "complete" means every single item the customer wants to see in the product, not only every single button but also every single label, that should be definable by reading the project specs or mockups. I think "forgetting things" is the first big mistake leading to under estimations. Add an estimate that you multiply by three in front of each, ie. if the dev…

ReRe's Law of Repetition and Redundancy [4] somehow does not apply to you:

  A programmer can accurately estimate the schedule for only the repeated and the redundant. Yet,
  A programmer's job is to automate the repeated and the redundant. Thus,
  A programmer delivering to an estimated or predictable schedule is...
  Not doing their job (or is redundant).
[4] https://news.ycombinator.com/item?id=25797519

Re: Software effort estimation is mostly fake research

#107

Post by didibus »

quickthrower2 wrote: post #90
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…

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. All you need is relative sizing between requests. This seems twice as much work as that but gives us half the benefit. Ok probably we shouldn't do this one first. And even then, often time impact is all you need for priorities. Like who cares what takes you longer, if you just focus on building the next most impactful thing you'll very often succeed.

The question of: "When are we going to be done this?" Is almost always irrelevant except for what I mentioned "asking for a quote". Like, who cares when it's done? What else you'd rather we do? I can tell you if your alternative will be any faster or not. And is this not the most impactful thing? If so, let's finish it and stop slowing us down with these irrelevant questions.

Now for headcount, it's the same thing. Look how much you did last year with what headcount. Ask yourself if what you're hoping to do this year is of the same relative size, twice as big, half as big, or smaller? And then plan headcount accordingly. If twice as big, double head count. Overtime you'll learn if twice as big requires doubling headcount or 1.5x or 1.2x or 2.3x etc.

Re: Software effort estimation is mostly fake research

#108

Post by 1337shadow »

ubercore wrote: post #62
cmroanirgo wrote: post #26

Earlier quoted context omitted.

Although this sounds flippant, the design process is where unknowns should be uncovered. It is easier to change design before a line of code is written. Design is precisely what is needed in order for the dev team to break down the projects into tiny chunks where nothing is unknown. Your time estimates should always include time for research and design. The customer can sign off on what you're about to write at the e…

Yeah but too many customers change their mind even after they've signed off. Then you're left with strictly enforcing a contract or making adaptations. You're right, design is very very necessary and should be given plenty of time. But it's not a magic bullet.

In terms of contract, I have found this works best (recommended by my lawyer (a former ASF lawyer)): 30% upfront, 50% at first delivery, then they have 2 months to find bugs, final delivery is when the bugs are fixed that's when you take the last 20%. This way, you're certain to always get 80%.

If they want the liberty to "change their mind on the fly" then they should buy man-days which is a completely other thing. Or, they can buy supplementary mandays for whatever they want at the daily rate without changing the contract, or, they can just wait to finish this contract and start another one.

Re: Software effort estimation is mostly fake research

#109

Post by btbuildem »

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 decades, and only truly useful new advances are integrated into workflows (for example, laser level vs plumb bob or spirit level).

In software, new technological approaches are adopted on a continuous basis, and so a lot of effort is spent on learning how to solve old problems with new tools.

Re: Software effort estimation is mostly fake research

#110

Post by Groxx »

One important thing I've managed to get a couple managers to track for quarter/half planning purposes: uncertainty. Prior to that, we'd of course hemmed and hawed and verbalized the fuzziness of our estimates... but only the final decided-on not-super-pessimistic number was written down, and decisions were made based on those. That was a major source of our estimating problems.

Everyone wants estimates. For decent reasons. But until we've done a similar thing before, they're utter fabrication. We can take a semi-educated guess, but we know they're still guesses... so for things we don't have concrete answers for, we give small/medium/large/extreme markers for how uncertain we are.

It's fine to take on a big unknown or two. You might even get them both done in a half. But they better be worth it (or you have to decide when to cut your losses), because completing those two could consume all of your resources... and if that happens and you didn't commit everyone to it up-front, you won't get it done this half. Making that tradeoff more explicit managed to get us signed up for fewer low-impact-but-highly-uncertain projects that would inevitably balloon out of control but never be cut.

Post reply on HN