How to become better at software estimations | Hacker News Reader

How to become better at software estimations

medium.com

67 pointsrmanev48 comments

My rule of thumb for the last 25 years has been: Double how long you think it will take you to do your bit, then go to the next set of units. e.g. 5 minutes becomes 10 hours 1 day becomes 2 weeks 2 weeks becomes 4 months When you write code it's easy to forget the testing, documentation, and process and people overheads of getting your code out of your head and into production.

Kirk: "Do you always multiply your repair estimates by a factor of four?" Scotty: "Yes Sir, how else can I keep my reputation as a miracle worker?!"

For estimating something (doesn't matter if it's software or what) this is a useful process:

Has something similar been done before?

How long did the previous examples take?

Why do you think this time will be different?

The last question is not to catch you out. Maybe typical splash pages take people a few days but you're really fast at design, or they needed more polish. If I take a week normally to write a blog post and know that this one is longer than usual, maybe I need to add some time. Perhaps you're adding some copy but this time it doesn't need to go through legal. Whatever the difference is, try and start with previous known data and then adjust from there.

You shouldn't predict it'll only take you a day to get this blog post out if it takes you a week every time and you've got to prepare for a talk at the same time.

More detail and an example from Kahneman:

http://www.mckinsey.com/business-functions/strategy-and-corp...

I find estimates really hard.

For example I'm building mobile apps and often the time frame depends highly on the people involved.

Often the problem isn't the implementation, but everything around it.

Getting the right stakeholders, not everyone who things they have something to say need to be heard.

Getting the right requirements.

Getting the info architecture right.

Getting the design right.

All this can take months.

Then there are things, that sound similar but are completely different.

Getting 30 screens done sounds like a repetition of 30 times, but some of them are simply messages or splash screens and some have crazy interactions with SVG, or API integrations or whatnot.

The last 2 apps I built were completly different.

One was a video/audio streaming app, with some micro blogging service attached.

One had a PDF editor and encrypted data storage.

I was always way under with my estimates. One day I was talking to some senior dev at another company and he said that he got better by multiplying his estimates by 3.

So I gave that a go, I'd do my estimates in one column then multiply them by 3 in the next column. At first I thought that those x3 estimates were way too high but 90% of the time they were about right, maybe a little over but it's usually better to be over than under.

After a while I just started landing on those x3 estimates without it being an extra step, I've been not bad on the estimation side of things since doing that little trick.

3 is rather arbitrary, we use Pi as the coefficient instead.

Now, this is science!

4 Pi around here!

I always use factor 3.

I just think: based on what I know now, how long would it probably take to write it - optimistic -?

Multiplying this by 3 is justified by the unknown unknows, bugfixing, communication, changing scope and assuming stuff is more simple than it actually is.

Works like a charm for me in most cases.

For problems where the solution is still unknown, I tend to break it up in small cycles, with a best-case estimate. At the end of every cycle we adjust and align, so that the customer can decide for himself whether to proceed, restart or abort.

"Multiply by π for small, known teams, doing a new job, by π^2 for unknown teams, and √π for known teams who have already started, know their work and have a good track record."

http://alistair.cockburn.us/The+magic+of+pi+for+project+mana...

I use π for new kinds of projects and the golden ratio φ for well known types of projects. (edit: however, the only purpose of an estimate might be to go faster, so perhaps it's better to have an unrealistic one)

I have found that if I ask some people for a quick estimate and multiply by 5, the estimate will be pretty close.

There's probably a litte bit of Parkinson's law in there.

This article may help:

Why Asking Developers for Time Estimates in Software Projects Is a Terrible Idea and How to Bypass It With Scrum: http://www.romenrg.com/blog/2015/09/28/why-asking-developers...

As a medium level developer (5 years of professional experience), estimations are always the bane of me. No matter how detailed I get, they're always off by enough to concern me.

No matter how detailed I get

That might be the problem.

A common scenario I've been through more than once is someone asks me for an estimate for some project idea they have. I ponder it for 30-60 seconds and say 6-8 month. They reply can you break that down. So I start breaking it down and breaking it down and then add up all the little pieces and end up at only 3-4 month. Project manager writes down 3-4 months and tell us to get to work. 6-8 month later we deliver and get yelled at for being late.

That's really good feedback, thanks. Next time around, I'll try to just leg it broadly and see what happens.

Little thin on content or message...

Got hung up on the first sentence. I'm on the egg comes first side and I believe evolution proves this point.

Not a chicken -> egg -> not a chicken -> egg -> chicken!

Evolution doesn't really deal with where a species splits in two. If anything, species don't exist. Its an abstract grouping of different entities that tend to be able to reproduce together. It only works thanks to in-between links often dying out. If you took a chimp and a human, and made a chain of every ancestor all the way back until you reached a common ancestor, you wouldn't be able to mark when one species becomes another.

We have a few such cases without needing to use time travel. We often refer to them as ring species, but a single ring species would become multiple species if you had one or two areas of the ring wiped out (based on if it is really an unbroken ring or an arc). That the death of one group of animals turns two other groups of animals from being one species into two shows the underlying problem with our classification system.

Thanks for your reply, glad to be educated in my limited biology knowledge :D. I think I understand your point. Evolution doesn't classify, we do. But doesn't this validate my point? Isn't the chicken vs egg question the same kind of problem made up by man like what we describe as different species? Apart from specialists there is no need for the majority of the population to classify the extinct variations of a ring species. So I assumed classification occurs vertical up to the common ancestor rather than horizontal by dying out variations of a ring species.

My original statement was simplified, maybe "evolution in conjunction with how mankind classifies species" would be more in line with the point I was making. My reasoning behind this is the following: As far as I know, the most accurate way of comparing species is by comparing genetic structure. And the point at which these genetic changes typically happen (maybe there are exceptions) is at reproduction (that's the evolution aspect of my point). This would also be the "earliest" point we could spot a difference.

When my estimates becomes correct, it means, I have a clear view of all the difficulties. Probably, the job becomes repetitive and I should try to find another one.

Hear hear... Sometimes I find myself avoiding to complete my pet projects just because I don't want to risk being bored.

If you enjoyed the article, you can check out Part 2 on Medium - https://medium.com/code-runners-blog/how-to-become-better-at...

As always, Martin Fowler has something to add on the topic: https://martinfowler.com//bliki/PurposeOfEstimation.html

Thanks BerislavLopac! Key takeaway from Fowler:

> "Estimation is neither good or bad. If you can work effectively without estimation, then go ahead and do without it. If you think you need some estimates, then make sure you understand their role in decision making. If they are going to affect significant decisions then go ahead and make the best estimates you can. Above all be wary of anyone who tells you they are always needed, or never needed. Any arguments about use of estimation always defer to the agile principle that you should decide what are the right techniques for your particular context."

The best book I have read on software estimation is: http://www.stevemcconnell.com/est.htm

My best short advice would be: always try to make an as detailed as possible list of tasks and estimate them independently - this way it is harder to forget about some details and when you estimate the tasks independently you sometimes over-estimate sometimes under-estimate and the errors compensate each other.

when you estimate the tasks independently you sometimes over-estimate sometimes under-estimate and the errors compensate each other.

Not in my experience. Under-estimate errors are basically always much smaller than over-estimate errors. Unknown factors that can dramatically speed up a projects are much fewer than unknown factors that can dramatically slow down a project.

I mean if nothing else a 4 week task can, at best, be delivered 4 weeks early, but there is no upper limit to how late it can be.

This. It strikes me as odd these days when managers and engineers assume symmetrical distribution of time required to complete tasks. This is not only relevant in software development: in my experience, the larger the organisation or set of people/departments involved in any kind of work, the heavier the time distribution is on the "late" side.

That was one of the things that burned us once we finally got our task estimates accurate. Most tasks would be finished in about the time estimated, but one would be off by a factor of ten and blow the iteration.

We discovered that for estimates to be accurate overall, most tasks need to be finished early. It's counterintuitive, but it's directly the result of that asymmetric distribution.

If you are systematically under-estimating (as most novice estimators - people tend to be optimistic) - then you can calculate how much you usually under-estimate and then adjust.

I never have time to make detailed list and I never get enough good specification from sales/business. Get 5-7 people in the room for planning meeting and try to do detailed list of tasks. For one hour you can tackle maybe one story or one and a half. I have backlog with 10-15 stories so 10hrs with 5 people is insane amount of money and you cannot do it in one day so it will take two weeks (1hr per day if all people have light schedule). In my experience such approach always ended up with complete disappointment, budget burned on arguments over nonsense.

I got this book recently because I loved Code Complete. I've read the first half, haven't had time to finish, but the key take away for me is that nothing really beats historical data.

In fact, he showed that even breaking down things into tiny details is not much help without historical data to base estimates on, or maybe I'm misremembering.

As a software developer, why would I want to get better at software estimation? At best, it means that I can give a rough comparison of the engineering effort required for different projects, which means that I get projects with a positive ROI (which still takes office politics to translate into actual career success, but it's still helpful). At worst, it yields power and control over my work life for no good benefit.

I'd get good at estimating in a hurry if you flipped the locus of control. Make management generate importance points, give me freedom to choose projects given importance points, and make importance points per engineer-week a Key Performance Indicator.

I find it much easier to estimate the time it will take if I take myself out of the picture. When estimating, I always try to think "how much time would it take for my colleagues to plan, execute, test, etc... something"? It is almost impossible to judge your own speed, but with experience you learn how to estimate speed of others quite accurately.

Of course, I also let product managers know that any change will affect the deadline, and almost never in a good way. I do this every time they have another "really simple idea".

This is standard advice for estimates. Yet most estimates are still wrong.

Well, they would be, being estimates. If they were right they'd be facts. The problem with estimation is that people view estimates as fact, when (according to Steve McConnell) all estimates should come with a variance of + or - 4.

I like to present my estimates using the cone of uncertainty, which demonstrates their fallibility well.

https://en.wikipedia.org/wiki/Cone_of_Uncertainty

The only helpful advice I ever got was to always multiply by π.

Yes the pi method was a favourite at my workplace.

Also multiplying by π makes it sound like there's a nice pseudoscientific reason why estimates should be off by that specific factor. You don't get that sciencey feeling if you multiply by 3.

(See also: using Fibonacci numbers for story points.)

Here at Big Co. we are very Agile. We always write up everything vaguely ahead of time and require estimates from developers which of course become hard deadlines. We are so Agile we always allow product people to request arbitrary major changes which are also estimated, but independently since clearly no changes affect any other, and they can all be done in parallel so the original deadline does not need to be changed. You see, the estimates are the key to successful projects. When the estimates turn out to be wrong we blame the programmers. It's a good system.

The fact that fudging it by 3, is now so popular, just indicates we can't really do estimates very well.

Or perhaps it's simply an empirical measure of the typical ratio of known to unknown in software engineering: 1:2. It can be used as a heuristic to accommodate for the fact that we have biases and can't predict everything, but the industry as a whole has found a way around that.

Starting point: Often, it's politics, not science or engineering [1]. Approach accordingly.

----

1) At least, once it comes to providing estimates outside of the assignment/team/project and its own internal thinking.

I'm glad to see so many people are interested in the topic and cared enough to comment. I'll be posting Part 2 in the upcoming days.

"Software estimation is a chicken and egg problem. So I will try to solve it from first principles: how long did it take for dinosaurs to evolve into chickens?"

Take your best estimation. Increase the unit by 1 and double the quantity.

Eg. 2 minutes becomes 4 hours. 10 days becomes 20 weeks. 6 months becomes 12 years.

Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

Reply on news.ycombinator.com