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

31–40 of 318 posts

Re: Software effort estimation is mostly fake research

#31

Post by jonpurdy »

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…

I agree that building and demoing something small is key. The larger and more complex a project will be, the harder it is to estimate.

I’ve been trying to distill this into a framework that is accessible to both development and business folks [0]. I've used it a few times and it has resulted in a few projects getting cancelled due to a massive difference in initially expected cost and post-analysis expected cost.

0 - It's basically just Scrum oriented towards providing upfront estimates. https://jonpurdy.com/pm-framework/how-to-quickly-plan-and-es...

Re: Software effort estimation is mostly fake research

#32

Post by monadic3 »

durandal1 wrote: post #21
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/framewo…

I'm sure Apple devotes time to research as well, even if it is under a different budget and/or department.

Re: Software effort estimation is mostly fake research

#33

Post by jakubp »

tootie wrote: post #25
jakubp wrote: post #17

Earlier quoted context omitted.

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.

Agree on the second point. I tried to convince some managers and sales guys to stop giving estimates at all and build trust otherwise, didn't work :)

As for consistent, my point was if you have 100 SP in backlog, delivered 50, then I contend you are not in the mid-point of the project. This is a dangerous assumption. You don't know where you are in my experience.

Re: Software effort estimation is mostly fake research

#34

Post by ChrisMarshallNY »

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't seem like it, on the surface.

The reason is that all those little things that go into high quality take lots of time.

I can write a pretty complete app that does some cool stuff in a day or two. I do it often, when I write test harnesses for my libraries and whatnot.

However, if you want that app to be ship quality, and highly usable, you're looking at over a month.

The thing is, many folks would consider my test harness lash-ups to be their "shipping" product, and will use that as a basis for estimation.

Re: Software effort estimation is mostly fake research

#35

Post by solumos »

wyldfire wrote: post #8

How do other disciplines estimate NRE? Do they have the same problems with missed predictions?

Well, lawyers take a retainer. Doctors are paid per-diagnostic-visit and per-procedure. Accountants bill hourly. Most professions have this - electricians, plumbers, locksmiths, etc.

This business model is normalized for other professions, and it should be for software engineering too. As a profession, we should move more towards partnering with organizations to realize business value through software rather than being simple "feature factories" (see also: Developer Hegemony[0]).

[0] https://daedtech.com/developer-hegemony-the-crazy-idea-that-...

Re: Software effort estimation is mostly fake research

#36

Post by munk-a »

bcrosby95 wrote: post #18
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…

I think it's because inexperienced programmers don't think about the "soft" costs of programming. Requirements gathering, general communication, testing, production rollout, coordination, research, final approval - it all adds up. For a 2 week project you might only actually spend a day of ass-in-seat coding. And that ass-in-seat coding is what they tend to estimate.

I think this is a big factor in estimation inaccuracy for really new programmers - but it is pretty well fixed by project managers following estimation rules of thumb - like double it and add five days... The bigger issue that I am less certain about being teachable is the experience side of things. I've worked in industry for a while and I know how long different sorts of patterns will take to write and what sorts of complications different sorts of add-ons will add to those numbers. Some projects are about where my naive brain fifteen years ago would put them and other ones are wildly different due to complexities that aren't visible in a surface level examination. Learning to sniff out those complexities seems to just take experience (not with every individual scenario - but it's a pattern analysis thing).

Re: Software effort estimation is mostly fake research

#37

Post by virgilp »

durandal1 wrote: post #21
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/framewo…

Adobe executes (executed) massive releases on a well-defined cadence (1.5 yr per "creative suite"). Sure, I won't say they don't have collaboration, or top-tier engineers etc. But in the end, the success of this well defined cadence boiled down to the simple strategy of "we release what is ready". Everybody knew the deadlines well in advance, and everybody strives to 'make it' - but, (not so) occasionally, some teams didn't and you could see entire features get ruthlessly cut out. Simply no other way of synchronizing across the entire company... you cut scope to make it in time, and if you can't make it, that's it, your feature gets cut. With enough teams working, you still get features to showcase at each release.

Re: Software effort estimation is mostly fake research

#38

Post by curiousllama »

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've been hearing this rule for years now, and I think the coefficient is increasing. It started at 1.5x, now it's at 3x... Is this just me?

Re: Software effort estimation is mostly fake research

#39

Post by Netcob »

Integrations for time-tracking software with issue tracking software exists, but I've never actually seen them used in combination before. You'd think that issue trackers would always include a very user-friendly time tracker by default, and advertise integrations with popular time trackers just to get that "actual time spent" data. I've also never looked at a burndown chart with any particular interest after knowing you can close an 8h issue after .5h and a .5h issue after 8h of work and the issue tracker will just keep pretending its charts mean anything.

Yet any company that does a lot of the same work could probably use that. You'd still need to do some extra work and tag your issues by things that you want to observe (and maybe predict), but then you could say things like "after we switched to that fancy new API client generator, our client development times went way down but debugging times went up a bit". And the system could display some time range while you're writing the issue. You could also look at the issues at the end of a sprint and then merge them with other items from the time tracker to see how meetings and other distractions played into the outcome.

Re: Software effort estimation is mostly fake research

#40

Post by 458aperta »

I disagree with the premise of this article. Software development is largely a waterfall process even if you use TDD (which was using a machine gun to chop down a tree) and the effort estimation is both predictable and consistent. At least with the model that we use in-house developed over the past 10 years that has resulted in several exits.

Don't rely on HN submissions to shape your view of the world. Pedantry, pendants waste your time. Only real world results and data matter. The people who can't do simply teach or publish papers so all you are left are people who grab a leg or an arm and think its an elephant in complete darkness. You simply will never ever find us publishing these information nor do others that have figured it out.

Transparency when it comes to winning trust is a must. Disclosures in the name of generosity or some collective good is lust; You might feel good but it ultimately results in increased competition and higher operating cost until your edge disappears. We are not in the business of helping our competitors, we use our unique edge to push them out of the market when we can, we use capital to buy them out when we can't.

Post reply on HN