6 ms·

Eh. I've been successful adding 20% in. I feel like if you have to double first (meaning your end result is 220% of what you originally estimated) then you aren

Eh. I've been successful adding 20% in. I feel like if you have to double first (meaning your end result is 220% of what you originally estimated) then you aren't learning from previous mistakes. Maybe 220 is appropriate for the first time you do work or work with a certain team tho.

nnq 7y ago
220% also works fine if each one of the projects is "practically unique" to you / the team... this happens >50% of the time in the real world, imo, because some fields have very little transferable skills/experience from project to project... a large percent of stuff is genuinely new every time and never repeats even if it's "basically the same thing as that other project"! (Or team composition changes.) Problem is the fact that you can only justify with a straight-face 45% (100%/220%) of the estimate you give to the client... Then you need to get clever at "bluffing" your way at "inventing" another extra +35% of work that you can't imagine/explain, but you know for sure that will come out of the blue - you know there's this extra 35% work needed for sure, you just have no idea what this work will be. Then finally you can say with a straight face that 20% of estimated time is for unforseen circumstances. There's two ways to see the same math: (1) 45% + 35% + 20% = 100% (2) 100% + 100% + 20% = 220% The world would be a much better place if clients / managers / project owners etc. would just accept that 55% of time & cost for software dev is unknown-unknowns type of unexplainable/unimaginable-at-project-start-stage-work. That's just how it is! If the problem was really clearly defined and understood, there would likely already be an off-the-shelf software solution for it that could be used instead of paying developers to build custom software! If we could just be honest with people and show them formula (2) instead of a make-up-ladden version of (1). But people don't, so we get to play the damn elegant-bullshitting game over and over again...
- Roark66 7y ago
  >Then finally you can say with a straight face that 20% of estimated time is for unforseen circumstances. This is how I always have done it across multiple jobs and I always called that extra contingency. Depending on the project I sometimes had to ask for over 50% of the total as contingency. If anyone queried it I would explain that it is very likely we'll need it based on my experience of many other projects. Then the client would either accept it as is, or they would want to split the proposal into "what we will definitely pay for" and "what we will pay for only when it is actually needed" which is also fine for both sides if proper progress reporting has been agreed in advance. Someone could think that no client would agree to such a contract as it would open them to be taken advantage of by an unscrupulous supplier, but at the end of the day what matters in business is trust. If a client doesn't trust the supplier they shouldn't hire them. And in all my previous projects I never met an engineer or developer that would deliberately use up the contingency time when it is not needed as everyone knows the availability of this extra time might come very important towards the end of the project.
  - thatoneuser 7y ago
    That's a smart way to do it. I used to put in ranges (basically contingency) of rate but I found myself consistently hitting a similar % of the higher estimate and just started quoting the higher estimate with the expectation that I'm not a God and there may be unknown factors which could add in more cost. Usually people are happy as you say if there's trust and you show progress.
crazygringo 7y ago
> then you aren't learning from previous mistakes ??? The doubling-it is for when you build the whole component on top of a library, then discover that the library has a fatal bug you can't work around, and you have to rebuild the whole component on top of a different library, then discover that other library has another fatal bug, so now you need to include both libraries with logic around when to use which one, and then that seems to work but you add plenty of tests and documentation to make sure it works that way in prod too and not just on your dev machine. I don't see what that has to do with learning from previous mistakes. Pretty much all but the most basic programming turns out to be like that -- dealing with unforeseeable and undocumented problems. (The 20% is because you weren't planning for sick days, an unforeseen emergency bugfix on another project, nobody remembered about the afternoon retreat next week, etc.)
- lostctown 7y ago
  Going through this now and boy is this true. Nothing like rewriting a 1k+ lib the day before a feature is supposed to be ready and then praying you didn't blow up some other lesser documented part of the code.
- thatoneuser 7y ago
  Yeah and I've been pretty good at estimating what to expect. I mean you'll always find surprises but personally I'm more inclined to quote a lower estimate and come back explaining the situation than to overcharge. But if you know of any clients who are throwing money around like that I'll gladly accept your 220% estimate for a few referrals ;)
- jdsully 7y ago
  Why not just fix the lib?
hannasanarion 7y ago
Wouldn't it be 240%?
- ambicapter 7y ago
  It would.
- dls2016 7y ago
  ambiguous grammar
- thatoneuser 7y ago
  No he said double or (200) then add 20 (220). Unless there's ambiguity I'm not seeing.
  - kthejoker2 7y ago
    Add 20% of the doubled estimate (eg .2 * 200%=40%) surely?
    - thatoneuser 7y ago
      Ah I see your point.

nnq 7y ago

220% also works fine if each one of the projects is "practically unique" to you / the team... this happens >50% of the time in the real world, imo, because some fields have very little transferable skills/experience from project to project... a large percent of stuff is genuinely new every time and never repeats even if it's "basically the same thing as that other project"! (Or team composition changes.) Problem is the fact that you can only justify with a straight-face 45% (100%/220%) of the estimate you give to the client... Then you need to get clever at "bluffing" your way at "inventing" another extra +35% of work that you can't imagine/explain, but you know for sure that will come out of the blue - you know there's this extra 35% work needed for sure, you just have no idea what this work will be. Then finally you can say with a straight face that 20% of estimated time is for unforseen circumstances. There's two ways to see the same math: (1) 45% + 35% + 20% = 100% (2) 100% + 100% + 20% = 220% The world would be a much better place if clients / managers / project owners etc. would just accept that 55% of time & cost for software dev is unknown-unknowns type of unexplainable/unimaginable-at-project-start-stage-work. That's just how it is! If the problem was really clearly defined and understood, there would likely already be an off-the-shelf software solution for it that could be used instead of paying developers to build custom software! If we could just be honest with people and show them formula (2) instead of a make-up-ladden version of (1). But people don't, so we get to play the damn elegant-bullshitting game over and over again...

Roark66 7y ago
>Then finally you can say with a straight face that 20% of estimated time is for unforseen circumstances. This is how I always have done it across multiple jobs and I always called that extra contingency. Depending on the project I sometimes had to ask for over 50% of the total as contingency. If anyone queried it I would explain that it is very likely we'll need it based on my experience of many other projects. Then the client would either accept it as is, or they would want to split the proposal into "what we will definitely pay for" and "what we will pay for only when it is actually needed" which is also fine for both sides if proper progress reporting has been agreed in advance. Someone could think that no client would agree to such a contract as it would open them to be taken advantage of by an unscrupulous supplier, but at the end of the day what matters in business is trust. If a client doesn't trust the supplier they shouldn't hire them. And in all my previous projects I never met an engineer or developer that would deliberately use up the contingency time when it is not needed as everyone knows the availability of this extra time might come very important towards the end of the project.
- thatoneuser 7y ago
  That's a smart way to do it. I used to put in ranges (basically contingency) of rate but I found myself consistently hitting a similar % of the higher estimate and just started quoting the higher estimate with the expectation that I'm not a God and there may be unknown factors which could add in more cost. Usually people are happy as you say if there's trust and you show progress.

crazygringo 7y ago

> then you aren't learning from previous mistakes ??? The doubling-it is for when you build the whole component on top of a library, then discover that the library has a fatal bug you can't work around, and you have to rebuild the whole component on top of a different library, then discover that other library has another fatal bug, so now you need to include both libraries with logic around when to use which one, and then that seems to work but you add plenty of tests and documentation to make sure it works that way in prod too and not just on your dev machine. I don't see what that has to do with learning from previous mistakes. Pretty much all but the most basic programming turns out to be like that -- dealing with unforeseeable and undocumented problems. (The 20% is because you weren't planning for sick days, an unforeseen emergency bugfix on another project, nobody remembered about the afternoon retreat next week, etc.)

lostctown 7y ago
Going through this now and boy is this true. Nothing like rewriting a 1k+ lib the day before a feature is supposed to be ready and then praying you didn't blow up some other lesser documented part of the code.
thatoneuser 7y ago
Yeah and I've been pretty good at estimating what to expect. I mean you'll always find surprises but personally I'm more inclined to quote a lower estimate and come back explaining the situation than to overcharge. But if you know of any clients who are throwing money around like that I'll gladly accept your 220% estimate for a few referrals ;)
jdsully 7y ago
Why not just fix the lib?

hannasanarion 7y ago

Wouldn't it be 240%?

ambicapter 7y ago
It would.
dls2016 7y ago
ambiguous grammar
thatoneuser 7y ago
No he said double or (200) then add 20 (220). Unless there's ambiguity I'm not seeing.
- kthejoker2 7y ago
  Add 20% of the doubled estimate (eg .2 * 200%=40%) surely?
  - thatoneuser 7y ago
    Ah I see your point.