4 ms·

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

by kator 12y ago

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.

d--b 12y ago
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.
anthay 12y ago
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.
- Ntrails 12y ago
  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
- kator 12y ago
  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.
- frederickf 12y ago
  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.
lnanek2 12y ago
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.
yarrel 12y ago
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.
patrickmay 12y ago
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.
- jgamman 12y ago
  i independently developed that rule! ;-) works well in most multi-discipline team based development projects

by kator 12y ago

d--b 12y ago

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.

anthay 12y ago

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.

Ntrails 12y ago
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
kator 12y ago
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.
frederickf 12y ago
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.

lnanek2 12y ago

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.

yarrel 12y ago

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.

patrickmay 12y ago

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.

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