Hacker News Reader

Comment by milesvp | Hacker News Reader

I find this interesting. I've been told that law schools teach that when estimating how long something will take (not how many hours of effort, but calendar time) they say to double your estimate, then increase the units by one. So what you think is a 2 hour task will actually take 4 days to complete. 4 weeks will take 8 months.

I wonder how much of that is professional wisdom that embodies this lognormal distribution. Law isn't quite the same as dev, since there can be a lot of lost calendar time just due to certified mail, or court dates, or whatever. But I've found that when I apply this formula to my estimates, I'm a lot less anxious when I start to bang my head against unforeseen setbacks.

Of course, knowing which value to emphasize to a manager depends on why they want the estimate. Sometimes they really want the effort estimate, and sometimes they want the calendar estimate, and I'll sometimes give both if the context warrants it.

View on HN

This points to another issue I've observed is that managers/operators ask for an effort-estimate and then map that directly to calendar estimate.

That and thinking that two 4h efforts can be completed in one 8h workday. MFer interrupt work so frequently how do they forget it happens? Forgot you had me in that BS 2h sales meeting "for show"!?

Yeah, but who do you think are in the best position to know what your calendar will look like?

You.

Always give calendar estimates. That is, after all, what matters to coworkers, to the business, to partners, to the customer, and to users.

That depends on whether you're in a position to set priorities. I can tell you that something will take a week, but I can't tell you that it will be done next week unless I'm permitted to work exclusively on it this week.

Nobody is ever able to work exclusively on a thing for stretches of a week.

I'd suggest starting to keep track of how much of your time you can take to work on the thing you work on. If it's between 30 % and 90 %, include that factor in your estimation procedure.

I think we're talking past each other. I'm not referring to a percentage of time being consumed by meetings and such; I'm referring to how frequently I'm asked to multitask because several urgent projects are going on at once. New priorities are added unpredictability, and sometimes I'm asked to clear all other work off my plate to fight some fire.

Of course that's a sign of trouble, but it's natural for the stage this company is at. (Note: different company than the one that did the lognormal study I mentioned a few posts ago, and a different role for myself, much more directly exposed to customer issues).

In an environment like that, calendar estimates are completely nonsense because the priority list itself is volatile on the timescale of the estimate. But work estimates can still be stable; I can still accurately report that I have eight hours of work left on issue A, and when I provide that estimate along with work estimates on issues B and C which are also assigned as "top" priorities, management can use that to decide whether I'll finish issue this week or not.

If you're sufficiently informed to know what your priorities will be on the timescale of an estimate, you can make reliable calendar estimates.

Maybe I fail to see the point of even bothering to estimate something that is so unimportant it can be (or even appears likely to be?) down-prio'd in favour of more important things so quickly.

Could you explain in what stage to switch between things so quickly few things are ever finished, and why it makes sense to estimate those things at all, in that context?

Early stage, need effort-budget to CBA vs risk to build calendar estimate.

The rule of thumb that I was taught for software delivery is to double it for every layer of management you have to deal with.

So if it's just you to a customer, 1 week becomes 2.

If it's you, reporting to your manager, to a customer 1 week becomes 4.

Although I generally don't apply multipliers this liberally, I do keep in mind how many stakeholders there are that can add uncertainty and friction to a project.

I've noticed that increasing the number of something usually indicates increases complexity. Working with another team takes more time than just keeping the work in one team. Working with two takes longer. Same with things like the number of repos, languages, or services.

That may be an expression of Brooks Law; increasing the number of people involved increases the average error count.

Reply on news.ycombinator.com