Hacker News Reader

Comment by wellpast | Hacker News Reader

This is false.

Software devs can become very good at estimation if you practice it.

Where 2 hours really is 2 hours—and even a week really is a week.

I know this from experience but it’s pretty basic to see that it’s true. A senior engineer (5+ years, say) is rarely encountering fundamentally novel problems. Most everything we do we’ve done before in some form.

To get good at estimation simply track how long things take. Over (short) time you will see that work is very predicatable and you can be very precise with your estimates.

If you buy this claim that ‘engineering work takes as long as it takes’ of course you won’t take the effort to get good at estimation and of course your lack of the skill will seem to reinforce your belief.

Don’t do that. Estimation is a highly valuable and acquirable skill. Acquire it!

View on HN

This goes against most of the rigorous studies in the industry which have consistently found, going on 50 years that no estimation techniques have high degrees of accuracy.

The only systems that do have high degrees of accuracy tend to throw out a big chunk of the work to get there (for instance some systems don’t estimate how long a proof of concept will take & only estimate post that).

I’d love to hear what your mechanism is for estimation that is repeatedly accurate & how to implement it at scale because otherwise it’s an open problem in the industry.

SEI at Carnegie-Mellon publishes copious resources on software estimation success and practice.

What references are you referring to?

I more or less gave the pattern — track your hours. I’ve been around the block...from large FANG companies to small startups across many varied tech stacks. Estimating an API design and impl in Java vs Python vs... Estimating impl a UI library in React vs some other server-side MVC framework... We are not inventing new bleeding edge academic paradigms — our work is estimatable.

If someone wants to pay me to teach the skill, sure...

But I can guarantee you you can estimate software efforts with accuracy.

Expert committee estimation (most commonly the Delphi method is cited) is one are that has shown improved estimation accuracy:

https://www.computing.dcu.ie/~renaat/ca421/LWu1.html

The SEI recognizing the weaknesses of expert judgement estimates has layered on QUELCE which applies Monte Carlo simulations to the estimates:

https://www.sei.cmu.edu/research-capabilities/all-work/displ...

Note that QUELCE is an ongoing research methodology without a lot of data available about its effectiveness. But it says something that this is a very active research area in 2018. If it were a solved problem I’d not think Monte Carlo distributions would be valuable.

The thing I've seen with estimation practice last I researched it is, it works best if you can calibrate. That's something an established shop can do by extrapolating from their previous work, but it is also often as simple as "This other team took 7 months to do a similar thing. Therefore we will also take 7 months." An estimate like that is usually only wrong by days-to-weeks, since it encompasses all phases, eliminating the fudge-factor, unknown-unknowns and wishful-thinking aspects.

When it takes much longer, it's almost always due to design issues or political issues that create design issues. When the design is well-understood(and prototyping is hugely important to finishing design ASAP) the implementation goes smoothly. When stakeholders take turns stirring the pot to "make their mark", it goes haywire very quickly.

Very rarely is estimation about simply the work required.

Estimation is normally off because something unexpected happens. Staging environment down, build server is broken. An external dependency takes longer than expected. On a new unfamiliar legacy code base where our previous work estimates no longer apply. Those unexpected problems vary widely in how long they take to resolve.

Yeah, if you estimate on a familiar code base, when everything goes right it's easy. But very rarely is that the case.

Exactly! Development tasks where the within-task technical software issues are the determinant of time estimation are so fleetingly rare that estimation is not useful as a general practice.

In fact I might even _define_ “senior engineer” as someone who has been around long enough to know this and has come up with some way to pacify managers with meaningless estimates in a way that protects the team so it can actually still do work.

After 15 years I still struggle to estimate how many times the client will change the requirements within an ~8 week project, let alone how long it will actually take.

Reply on news.ycombinator.com