Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

A lot of these articles assume the work being estimated will remain relevant during the estimated timeframe. My last (very large, not FAANG) employer started every project with a hard deadline, estimates were only used for budgeting not time, and then every project changed on a daily basis until it was obvious it would never ship by the deadline which was changed at the last minute. Every single project worked like this (note these projects were for us not external clients). I know of no theory of estimation that can account for continuous change unknown at the start.


I've worked on reasonably large >$100M defense programs for the last 25 years. Nearly all of them overran both time and budget constraints. They have mostly been firm-fixed price, except for the last 5ish years, that being incentivized agile. I have seen estimation be accurate when the following criteria are met :

1) Experienced personnel are estimating the work (experienced technically and in the product being developed); 2) The work being estimated is of similar technology to existing product; 3) The time period being estimated is less that 6 months

If any of these are violated, e.g. new hires are given the estimation task, a years worth of work is being estimated, new technology is being estimated etc, i would not trust the estimate, and apply big 'ol bucket of risk money.


I actually have seen this legitimately work as well, as in being on a program where we pretty consistently hit every deadline with every planned feature at or under the promised price, for years on end.

But then take the same company, even many of the same people, and put them on a new project, and the estimates go to crap.

It really takes a lot of domain-specific experience, and I mean "domain" pretty narrowly, like knowing the code base, knowing the developers, knowing the customer, knowing the external surprises and constraints you're likely to come across because you've seen them so many times before. I've never seen it work for greenfield, even in an organization with the discipline and know how to do it correctly for their older applications they've been working on for years or decades.


What does "accurate" estimation mean to you? 50 % of things completed within that time? 90 %? Something else?


In other words, "estimates" are actually just political and budgetary tools. They have no relation to real-world work. One side agrees to call them "estimates" (the product side) and the other side (the business) agrees to let deadlines inevitably slip.


Perhaps techniques from meteorology [1] could be applied to creating continually evolving estimates for software development.

[1] https://www.ametsoc.org/index.cfm/ams/about-ams/ams-statemen...


We right now use astrology so it will be an improvement




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: