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

21–30 of 318 posts

Re: Software effort estimation is mostly fake research

#21

Post by durandal1 »

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…

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/frameworks teams does it AFAIK, and I do think it's incompatible with shipping on a hardware-aligned schedule.

Re: Software effort estimation is mostly fake research

#22

Post by chaz72 »

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…

Yes! I try to always phrase it as "the part I can see from here will take at least X time".

Re: Software effort estimation is mostly fake research

#23

Post by Ericson2314 »

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…

Yes, and if you find yourself getting better at estimation, that's probably because you have failed to build proper abstractions. With proper abstractions, the cost of the same stuff should be minimal, so the part with no good priors predominates.

Re: Software effort estimation is mostly fake research

#24

Post by [deleted] »

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…

[deleted]

Re: Software effort estimation is mostly fake research

#25

Post by tootie »

jakubp wrote: post #17
tootie wrote: post #3

Scrum dogma is that estimates are for complexity, not effort or timing. The points you track in JIRA are meant to reflect how much of the current backlog is complete and how much is remaining. That can be extrapolated into timing but can't be done up front.

If it can't be done upfront it's largely useless for business folks ("so you have an estimate but can't translate it into time? so why do it? go away" :). If it assumes remaining work is equivalent in time to done work (notion of velocity), it's (in my view) very optimistic. People learn the nature of the beast as time progresses. Collective learning happens slowly. A lot of important work is usually only discovered…

For one, it doesn't assume pace is consistent. Tracking velocity is part of the game too and it can vary with capacity, talent and maturity.

Secondly, telling business that we can't estimate accurately is more useful than saying we can estimate accurately and being wrong (which is guaranteed). It's a tough sell but it's necessary.

Re: Software effort estimation is mostly fake research

#26

Post by cmroanirgo »

csours wrote: post #14
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…

> "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.

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 end of that (whereas beforehand you give them a wild ballpark figure made by senior devs - not management!)

Re: Software effort estimation is mostly fake research

#27

Post by shihab »

I have been involved in Software engineering research a bit, even have a first-author short paper. I was struck by just how much pointless, low-effort papers there are in this domain. People have been researching about bug prediction for over two decades now, and judging by the paper quantity, this isn't a niche area. Yet how many organizations do actually employ those systems in real-world? Can't comment on industry, but I haven't found a single open-source program that does that [1].

Now I know "most papers are pointless" is a common complaint in science, specially in my area of focus- machine learning. But I can't shake the feeling that the situation is particularly worse in software engineering related academic research.

[1] I saw Mozilla attempt it, but not sure if it's currently in use.

Re: Software effort estimation is mostly fake research

#28

Post by jakubp »

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…

I've done backlogs before; both very high-level and very detailed; with and without mockups (even final graphic designs) and detailed description in the form of multi-page spec or user stories (depending on the fashion of the decade I was doing it in :).

I don't think having the detailed requirements made estimates much more accurate. However it made creating those estimates take an order of magnitude longer - developers needed much much more time to absorb all the details.

At that point I decided I only ever want to work with senior developers who have good imagination and can give reasonable triplets (solution, # of devs to do it, approximate time) for requested pair (idea, quality level).

Re: Software effort estimation is mostly fake research

#29

Post by kilroy123 »

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 couldn't agree more. This is what I do.

Re: Software effort estimation is mostly fake research

#30

Post by OneGuy123 »

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.

This, the famous "prediction* Pi" rule seems to be correct also in my experience.

I make the most optimistic prediction and then * PI.

Post reply on HN