Software effort estimation is mostly fake research • Hacker News Board

Re: Software effort estimation is mostly fake research

#11

Post by sound1 » Mon, Jan 18, 2021, 7:46 PM UTC

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…

As long as humans are involved in defining requirements, inaccuracy of estimate will be proportional to the cusomters' incompetence and level of bad politics of the organisation as a whole ;-)

Re: Software effort estimation is mostly fake research

#12

Post by domano » Mon, Jan 18, 2021, 7:46 PM UTC

I noticed that my estimates usually end up 3x as high as the next one and i feel pretty confident about them

Re: Software effort estimation is mostly fake research

#13

Post by cmroanirgo » Mon, Jan 18, 2021, 7:46 PM UTC

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…

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, where nothing went longer than 3 days (for inexperienced), but longer for more experienced. Senior devs should be able to be able to be trusted (to be accurate) for week-long blocks.

Use a Gannt chart (ms project or similar) and monitor the inexperienced, gauging their real-life times with their estimates, adjusting accordingly. Give semi regular feedback at the accuracy so that they (& you, the manager) are working with.

In one of my companies, the most inaccurate we were for any project was that we were late 2 days over 2 years. Build on trust, build on meetings and other time sinks. Include testing, sign offs, etc.

So, absolute n00bs need close mentoring so that the (senior) mentor can begin to gauge the growth rate... Which will be steep... But different for everyone.

Re: Software effort estimation is mostly fake research

#14

Post by csours » Mon, Jan 18, 2021, 7:47 PM UTC

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…

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

Re: Software effort estimation is mostly fake research

#15

Post by neartheplain » Mon, Jan 18, 2021, 7:48 PM UTC

Reminds me of the excellent 2010 talk, “What We Actually Know About Software Development, and Why We Believe It’s True”:

https://vimeo.com/9270320

Bit long, but well-presented and worth a listen for any practicing software developer (or person who manages developers).

Re: Software effort estimation is mostly fake research

#16

Post by jadams3 » Mon, Jan 18, 2021, 7:48 PM UTC

The most useful piece of advice I have gotten for estimates is that they are all junk until someone sits down and tries to do the work. For big jobs, 20% of it, small jobs pushing 50% of the work.

In every single case when you've done that much work, I seem to wind up with a reasonable estimate.

If we've done the job before and have data on it, also reasonable.

Double or triple anything else.

Re: Software effort estimation is mostly fake research

#17

Post by jakubp » Mon, Jan 18, 2021, 7:49 PM UTC

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 and planned in the second half of the actual (not original) timeline. A lot of important stakeholders are naturally only introduced into projects close to its finalization, which creates a flurry of new activity and discoveries. This makes projects late.

But where that real halftime is - most people I worked with rarely know. I was no better, I also rarely knew.

The only way to manage this I found was the basic rule: build, demo, decide what to do next. Don't get attached to original backlog and grand plans for the future. It won't work that way. Just build and make it work, launch ASAP, get decisions on a ~weekly basis done. Ignore long term planning. It's not helpful.

Sadly, few business folks want that of course :)

Re: Software effort estimation is mostly fake research

#18

Post by bcrosby95 » Mon, Jan 18, 2021, 7:51 PM UTC

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.

Re: Software effort estimation is mostly fake research

#19

Post by cmroanirgo » Mon, Jan 18, 2021, 7:51 PM UTC

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

Re: Software effort estimation is mostly fake research

#20

Post by jakubp » Mon, Jan 18, 2021, 7:54 PM UTC

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.

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 :)