Comment by kator | Hacker News Reader

Comment by kator | Hacker News Reader

Parent Full thread

I've been developing for 30 years. When asked for an estimate I spend time thinking about it and then when I come up with a number I multiply it by 3. Usually this works but sometimes I can be off. My typical process is to score stuff from "totally get it" to "don't have it all in my head". I then guess on hours and in the end multiply by this 3 factor.

When my clients complain about the estimate I often say we "write software":

   1) The way the client thought it should be written
   2) Again the way the developer thought it should be written
   3) And finally the way is should have been written in the first place

I don't remember where I picked this up at, it was eons ago, but the axiom seems to work.

When my teams give me estimates I almost always fudge by this 3x factor when working with my stakeholders and explain how hard it is to really estimate development without wasting tons of time doing massive waterfall charts. Then they ask for the chart and I laugh "but then it'll be wrong two seconds after we publish it."

In all my years of coding there have been "wow that went fast" times on projects and "oh man I'm dying here" and the more room I leave to reduce stress in the "dying" phase the easier it is to break free and get back to "fast" mode.

Take your original estimate, double it, and move to the next higher units. A one hour job ends up taking two days. Two weeks goes to four months.

Scarily enough, I've worked with people whose multipliers are this large.

i independently developed that rule! ;-) works well in most multi-discipline team based development projects

I multiply by three. My justification for this is that coders think only of coding time, and that the rest of the time is taken up with communication etc.

I tested this against an expert management estimate once. The difference was less than ten hours over several months.

When I'm writing a contract I usually put this in the milestones I'm paid by. E.g. one week for feature 1 delivery, next week for client requested adjustments to it, next week for feature 2 delivery, week after for client requested adjustments, etc..

Generally I only pick something I could finish in half a week for the 1 week milestone too, so there is plenty of time if it turns out tougher than I thought.

This is also a good way to communicate that you won't tweak a feature every week for months after without adding another milestone (and more pay) to compensate, something every client always asks for in the end, because you don't really learn anything until a feature is put in front of an end user.

But you risk your manager (if you have one) telling you you are "sandbagging." And you might see others on your team tell your manager "it's no big deal - an hour or so of work". And they slap some crap in there that whacks the mole down long enough for the manager to make a mental note to give your team mate a bigger raise than you.

If you want shitty work that creates a mountain of technical debt, I can do that (no, really, I'm a natural at it).

If you want a thought through process that covers all of the points as best I can, I will do that.

Align my incentives. But don't complain because I do the optimal thing

If you can't have a good relationship with your stakeholders then you should find a new stakeholder not sweat what someone else is willing to do to get ahead.

In the end if you're reasonable and can show you've hit the nail on the head often enough to be trusted then you won't have conversations about sand bagging.

I agree. This can be problem. Even if they don't slap some crap together. They may in the end take just as long (or longer) than your estimate, but by that point nobody remembers who estimated what. Just that you were the pessimistic one who wasn't confident and they were the eager go getter who solved the hard problem.

It's exactly the same thing I have been doing. This is a common project management practice. If you translate this practice in the terms of the original article. This is a kind of double thinking. You know the time it's going to take you, but you also know that you need to multiply it by 3 for it to be correct.

Reply on news.ycombinator.com