3 ms·

estimates are supposed to be just that. You then compare them with what actually happened, then you can work out if the estimates correlate well with work gett

estimates are supposed to be just that. You then compare them with what actually happened, then you can work out if the estimates correlate well with work getting done. The whole point of that is you can then start making decisions about scope / timeframe. If it's not used to make decisions about scope and time frame, then don't do it.

pdimitar 9y ago
> estimates are supposed to be just that. You then compare them with what actually happened, then you can work out if the estimates correlate well with work getting done. Impossible, unless you work in a very narrow scope. Examples: (1) I had to add several new parameters to an endpoint that accepted data from HTTP forms. It was a pain since there were mechanisms in the code nobody documented. Estimate: 1 day. Done: 2 days. (2) I had to make phone numbers mandatory if your physical shipping address is in a certain USA state. Estimate: 3 days (loads of JS written by previous team). Done: 2 hours. Reason: they actually added an engine for such dynamic rules; after doing due diligence, the work was walk in the park. (3) I had to allow a small part of our endpoints to be able to save to two different data stores. Estimate: 1 week. Done: 4 weeks. Reason: hardcoded Oracle SQL everywhere, had to rework 50+ modules several times. (4) I had to improve helper modules that cached data from remote API that was painfully slow to proxy through. Estimate: 3 days. Done: 3 weeks. Reason: the current code that cached stuff was extremely superficial, didn't deal with cache expiration, and it didn't even work part of the time. I can go all day. Point is, when you can do a lot, you get assigned a lot, and usually they are pretty different tasks. You can't reasonably draw any meaningful conclusion, except one: that an individual is over-estimating themselves. And even that is not always true because even at 37 I still don't expect at least half of the stupidities I find in legacy code that I have to maintain and evolve as part of a contract. I try very hard to not to be an ass, meaning I do not assume everyone is an idiot. From my perspective I give realistic estimates. In retrospect however, I probably should've assumed the worst 19 out of 20 times.
- keithnz 9y ago
  It's not impossible. Your examples are what orginally was the reason for massive massive emphasis on code quality and automation ( I started out with Extreme Programming in 99 ). Your examples are actually the whole point, if your code base becomes such that estimates vs actual does not correlate very well, then you don't use it to plan, you have too much variation. You look at what the cause of all the variation is, then sort it. It's actually good when it's no good for planning, it means you should have a bunch of obvious things to improve. Estimates were, in the XP world at least, virtual. You could give them a unit of "JellyBeans" so tasks were either a 1, 2 3, 4 JellyBean level of effort. Then you tracked how many jellybeans you get done in a time interval. Plan based on how many Jellybeans you got done in the last time interval. You track the variation. If your variation essentially means it's not predictable, then you look at why, and improve that. You as an individual should also be concious of how you are estimating as well, if you "should've assumed the worst 19 our of 20 times" then do that. IT'S THE WHOLE POINT. It's a feedback mechanisim. It's really important you don't blindly do planning with estimates if it's not working. It's meant so you can make reasoned choices about scope to achieve a particular time line. - so either variability is good meaning you make reasoned choices about scope - OR it's bad, and you make reasoned choices about improving the code base.
  - pdimitar 9y ago
    Well, we don't actually disagree. :) What I am saying is that estimates, even wildly incorrect ones, are over-valued and over-used. You seem to agree with that. I was pretty self-conscious (still am) in why do I mis-estimate but truth be told, nothing much can be done most of the time. If you go the cautious route, management tells you "that's too long, reduce it". If you reduce it, it's very likely you'll miss that now imaginary estimate, and the whole thing restarts itself for yet another vicious cycle. If you overwork yourself and manage to meet the near-impossible deadline, this becomes the baseline expectation for your productivity. One you cannot maintain for long. Yet again, management is unhappy afterwards. All of what you said I can easily agree with... if we the programmers had actual decision power in the managerial hierarchy. Which we don't.
    - keithnz 9y ago

pdimitar 9y ago

> estimates are supposed to be just that. You then compare them with what actually happened, then you can work out if the estimates correlate well with work getting done. Impossible, unless you work in a very narrow scope. Examples: (1) I had to add several new parameters to an endpoint that accepted data from HTTP forms. It was a pain since there were mechanisms in the code nobody documented. Estimate: 1 day. Done: 2 days. (2) I had to make phone numbers mandatory if your physical shipping address is in a certain USA state. Estimate: 3 days (loads of JS written by previous team). Done: 2 hours. Reason: they actually added an engine for such dynamic rules; after doing due diligence, the work was walk in the park. (3) I had to allow a small part of our endpoints to be able to save to two different data stores. Estimate: 1 week. Done: 4 weeks. Reason: hardcoded Oracle SQL everywhere, had to rework 50+ modules several times. (4) I had to improve helper modules that cached data from remote API that was painfully slow to proxy through. Estimate: 3 days. Done: 3 weeks. Reason: the current code that cached stuff was extremely superficial, didn't deal with cache expiration, and it didn't even work part of the time. I can go all day. Point is, when you can do a lot, you get assigned a lot, and usually they are pretty different tasks. You can't reasonably draw any meaningful conclusion, except one: that an individual is over-estimating themselves. And even that is not always true because even at 37 I still don't expect at least half of the stupidities I find in legacy code that I have to maintain and evolve as part of a contract. I try very hard to not to be an ass, meaning I do not assume everyone is an idiot. From my perspective I give realistic estimates. In retrospect however, I probably should've assumed the worst 19 out of 20 times.

keithnz 9y ago
It's not impossible. Your examples are what orginally was the reason for massive massive emphasis on code quality and automation ( I started out with Extreme Programming in 99 ). Your examples are actually the whole point, if your code base becomes such that estimates vs actual does not correlate very well, then you don't use it to plan, you have too much variation. You look at what the cause of all the variation is, then sort it. It's actually good when it's no good for planning, it means you should have a bunch of obvious things to improve. Estimates were, in the XP world at least, virtual. You could give them a unit of "JellyBeans" so tasks were either a 1, 2 3, 4 JellyBean level of effort. Then you tracked how many jellybeans you get done in a time interval. Plan based on how many Jellybeans you got done in the last time interval. You track the variation. If your variation essentially means it's not predictable, then you look at why, and improve that. You as an individual should also be concious of how you are estimating as well, if you "should've assumed the worst 19 our of 20 times" then do that. IT'S THE WHOLE POINT. It's a feedback mechanisim. It's really important you don't blindly do planning with estimates if it's not working. It's meant so you can make reasoned choices about scope to achieve a particular time line. - so either variability is good meaning you make reasoned choices about scope - OR it's bad, and you make reasoned choices about improving the code base.
- pdimitar 9y ago
  Well, we don't actually disagree. :) What I am saying is that estimates, even wildly incorrect ones, are over-valued and over-used. You seem to agree with that. I was pretty self-conscious (still am) in why do I mis-estimate but truth be told, nothing much can be done most of the time. If you go the cautious route, management tells you "that's too long, reduce it". If you reduce it, it's very likely you'll miss that now imaginary estimate, and the whole thing restarts itself for yet another vicious cycle. If you overwork yourself and manage to meet the near-impossible deadline, this becomes the baseline expectation for your productivity. One you cannot maintain for long. Yet again, management is unhappy afterwards. All of what you said I can easily agree with... if we the programmers had actual decision power in the managerial hierarchy. Which we don't.
  - keithnz 9y ago