I’m not sure what the alternative is, in any field, unless your work is so boutique and specialized that nobody else does it (auteur filmmakers, maybe). I used to work in a design firm where estimates were even more meaningless than in software. We all hated estimates but we all knew nothing would get done without them.
Ask HN: Why do software companies still insist on Estimation?
21–30 of 39 posts
Re: Ask HN: Why do software companies still insist on Estimation?
#22Let's talk about the reality of software development. Some projects are easy to estimate, especially in domains a developer has tackled before. As an example, consider a developer who has written five static pages who's asked to estimate how long it'll take them to write a sixth. Think of these projects as a well-defined path through the meadow to success. However, some projects are closer to crossing glacier for the…
> In their mind, that "I guess 3 months" estimate a developer gave quickly turns into "I can 100% deliver this to you fully tested, with all of the additions you added along the way in 3 months". This is my biggest trigger, when a vague, hand-wavey estimate is turned into a signed guarantee, then the developer gets disciplined or treated as a problem creator when more detailed information comes in. I found this was t…
Not giving vague hand-wavey estimates seems like a solution to that problem.
Re: Ask HN: Why do software companies still insist on Estimation?
#23Estimates or scientifically wild ** guesses (SWAGs) can be an incredible feedback loop to peers, a team, or an organization.
For peers, far apart estimates might indicate differences in understanding of the problem/solution.
For a team, if they are wildly diverging or low-certainty it can indicate the right next step is experimentation or exploration, rather than committing on delivering something to production.
For an organization, they can provide a barometer for investment decisions, such as what the appetite to solve a given problem space is, or how to evaluate sunken costs.
I particularly like a progressive framework on estimates, i.e. 10% certainty when a project is just taking shape, 20% when scope gets tightened up, 50%+ after spikes / rfc drafting / design etc.
Often they are used for rote accountability, which can be detrimental and/or naive - they should be a stake in the ground to have discussions around risks, assumptions, and trade-offs!
Re: Ask HN: Why do software companies still insist on Estimation?
#24This take lacks nuance, better to ask why software estimation is hard. To name a few reasons:
1. Business pressures to 'accelerate' timelines without understanding the tradeoffs
2. Frequent developer turnover / ramp-up time
3. Developer + engineering manager level of competence, mostly due to people going where the money is and it being difficult to assess skill level
4. 4-year degrees teaching very few applicable real-world skills and bootcamps teaching even less
Re: Ask HN: Why do software companies still insist on Estimation?
#25Earlier quoted context omitted.
well, it isn't really true. you should be able to estimate a project within an order of magnitude of time in the vast majority of instances. Think of 1 day 1 week 1 month 3 months 6 months 1 year 3 years if you had a random project, do you think you wouldn't be able to pick the most likely estimate and be within one level above or below? so "i have no idea, it'll take as long as it takes" is not really true.
Even this can be really deceiving, maybe core APIs to crucial libraries get removed. As a response maybe the team either needs to migrate to a new library, or rebuild the APIs from scratch. A situation like this can turn a "X days" task into an "X months" task. I know it is not super realistic but it represents a type of situation.
there's a big difference between "we can make a reasonable estimate based on X assumptions with Y dependencies, but there is a risk we are wrong" and "it will take an undefined amount of time, estimation is useless"
Re: Ask HN: Why do software companies still insist on Estimation?
#26Why do software engineers insist on being paid when they never deliver any working software? Imagine a world in which programmers were only paid once their code hit production. My hypothesis is that estimation skills would improve at a geometric rate. Said differently: good programmers are not afraid of making estimates. This classic article says it all better than I could: https://www.kitchensoap.com/2012/10/25/on-b…
If you deliver incremental improvements frequently enough people stop asking for promises, estimates and schedules.
The reverse is also just as true, of course.
Re: Ask HN: Why do software companies still insist on Estimation?
#27Why do software engineers insist on being paid when they never deliver any working software? Imagine a world in which programmers were only paid once their code hit production. My hypothesis is that estimation skills would improve at a geometric rate. Said differently: good programmers are not afraid of making estimates. This classic article says it all better than I could: https://www.kitchensoap.com/2012/10/25/on-b…
If you follow CD practices you will delivering working software all time.
It doesn't mean you know what feature is going to be delivered in 32 weeks in the future though.
Re: Ask HN: Why do software companies still insist on Estimation?
#28How would rest of the organization work if every new feature and bugfix would never have expected delivery date and everything was done "when it's ready"?
I understand your point and estimating is never easy, but software engineering alone won't keep the company a float
Re: Ask HN: Why do software companies still insist on Estimation?
#29When you hire a contractor to redo your kitchen, do you ask how long it may take? When you order food online, do you expect to know when it will arrive? When you go to your mechanic for a repair, do you want to know when you may get your car back? When you go to a lawyer to verify a contract, do you need to know when they will be done? Why should building a software solution be any different?
> When you go to your mechanic for a repair, do you want to know when you may get your car back? I want! However, for my old 2000 car, repairs exceeded the original estimate 80% of the time, forcing me to change my day-to-day plan. This could be a hint: good/new things breaks less, giving you false confidence when estimating for old/bad stuff.
100% complexity beats assumptions
Re: Ask HN: Why do software companies still insist on Estimation?
#30A trick I learned a long time ago, that is very helpful in old structured code style (e.g. C, mostly-class-free Python, some subsets of C++ -- but rarely Java) is to estimate the number of non-comment lines for each task, rather than the time needed.
This turns out to be much easier to reason about, discuss with colleagues, calibrate one's intuition etc; If one person thinks it will take 100 lines at the end, and another thinks it will take 1200 lines at the end - it provides a more concrete discussion when trying to resolve the difference than "10 days vs. 3 months".
And the number of bug-free structured-programming-style lines a programmer produces per day is surprisingly low variance, when measured at the end of a project. (And ... the mean is often in the 1-10 range for good projects and good programmers for places that require high quality like medical devices or aviation). If that sounds too low to you - consider a project 6 years in the making (~2000 days) worked on by 50 programmers. That's 100,000 programmer days. If it has 1M non-comment lines, it's only 10 per days on average.
Somehow, I've never been able to apply this to Java code or classful Python code, and have never met anyone who was - I suspect it's because these projects are dominated by boilerplate and huge bureaucracies, which weren't prevalent in the old days when this trick was devised.
(Which is not to say that object oriented programming and classful Python and Java are bad; Just that they seem to be resistant to this form of estimation)