7 ms·

Why blame the programmer? Bad estimates, like bad anything, have all kinds of possible causes. The programmer's "estimating weakness" is just one possible (and

by edw519 14y ago

Why blame the programmer? Bad estimates, like bad anything, have all kinds of possible causes. The programmer's "estimating weakness" is just one possible (and often unlikely) cause. In general, A. People do stuff. B. Programmers write code. C. People do stuff. so don't automatically blame the programmer for fuck-ups in Phases A or C. More specifically, one of my recent real world examples: http://edweissman.com/it-takes-6-days-to-change-1-line-of-code http://edweissman.com/it-takes-6-days-to-change-1-line-of-co...

ThomPete 14y ago
Exactly! It has nothing to do with the programmer. It has everything to do with what projects really are today. 1. Undefined in scope even when defined 2. Problems to be solved (innovation) not solutions to be produced (production) 3. Filled with hidden complexities of potential infinite character. Copied from another post of mine: Time estimations is an industrial way of thinking applied to a post-industrial (and post-capitalist) world. In the post industrial world time isn't the problem but rather project definition and scoping. In the industrial world the problem was already solved (machine was built, market often established and output depended on a few factors that could be adjusted. Need more output add more of X) In the post industrial world every project is about problem solving and scoping. To put it into comparison. If we apply post-industrial reality to an industrial world. It means that each time a product needed to be done if not the factory, then the machines would have to be developed. It will take many many years before time estimation will die, but it will happen.
- ahsteele 14y ago
  Do you have a link to that post? I really like your summary here and would like to link to it directly, outside of linking to this comment.
brudgers 14y ago
Bad estimates are bad because they don't meet the requirements, not because they are inaccurate. In some corporate cultures, a bad estimate is one that says that The Plan is unrealistic. Other times, management wants a best case estimate (which will be modified based on historical inefficiency) and bad estimates would include ones in which the estimator accounted for normal pessimism. On the other hand, if one is seeking an accurate estimate and A and C are part of the critical path, then they must be accounted for by the estimator. "Shit happens" isn't an excuse for an inaccurate estimate, a good estimator accounts for it.
- ThomPete 14y ago
  But you can't define your way out of the problem. Meeting the requirements have nothing to do with what it takes to meet them. Two very different things.
  - brudgers 14y ago
    The grandparent comment used the term "bad estimate" without acknowledging that the only thing which distinguishes a bad estimate from a good estimate is that bad estimates come back to bite you. My post indicated that the ways in which estimates come back to bite varies based upon the reasons for estimating in the first place, e.g. when the context is "it takes as long as it takes" there isn't a reason to estimate. The first set of estimates I describe are those in which the estimate comes back to bite you before the work has begun. An example would be an estimate within a publicly traded company which conflicts with the information provided to Wall Street, i.e. the purpose of the estimate is to confirm that all is well so that management can collect their quarterly bonus based on stock price. In another life I participated in those. The second group of estimates I describe are created to allow management to apply a single big picture fudge factor to account for big picture inefficiencies, contingencies, and information flows such as those which arise from external contracts. When management asks for a best case estimate in good faith, it is uncommon for the inaccuracy to come back to bite the individual providing the best case estimate. The inaccuracy is known going in, and the final estimate is of the third type I describe...i.e. it attempts to account for "known unknowns" and even "unknown unknowns." The third category of estimate is the only one for which people should be held accountable in regards to accuracy, and any accountability has to be related to the experience and authority to allocate resources of the person preparing it. Treating accurate estimates as impossible is a cop out. They are done all the time. It just takes experience and feedback and a desire for improvement.
    - ThomPete 14y ago
      I know companies who are good at estimating because they never change how and what they give a client. The designers are forced to design for the CMS. If all you need to do is to change things then yes it's possible to project fairly accurate. But in most cases where time estimation matters you can't just use past experience to estimate how much a new project is going to take you. Those are projects where you are innovating/creating/defining a new solution. So calling it a cop out is seriously underestimating the problem and discussion where it's most important not to.
wildmXranat 14y ago
Aaaaannd that's how people learn to cover their track and responsibility by shrouding each step in mountains of process controls and unwritten ^shudders^ protocols. Mind you, just sending straight to production isn't a panacea, but I couldn't help but laugh all throughout reading of the article

by edw519 14y ago

ThomPete 14y ago

Exactly! It has nothing to do with the programmer. It has everything to do with what projects really are today. 1. Undefined in scope even when defined 2. Problems to be solved (innovation) not solutions to be produced (production) 3. Filled with hidden complexities of potential infinite character. Copied from another post of mine: Time estimations is an industrial way of thinking applied to a post-industrial (and post-capitalist) world. In the post industrial world time isn't the problem but rather project definition and scoping. In the industrial world the problem was already solved (machine was built, market often established and output depended on a few factors that could be adjusted. Need more output add more of X) In the post industrial world every project is about problem solving and scoping. To put it into comparison. If we apply post-industrial reality to an industrial world. It means that each time a product needed to be done if not the factory, then the machines would have to be developed. It will take many many years before time estimation will die, but it will happen.

ahsteele 14y ago
Do you have a link to that post? I really like your summary here and would like to link to it directly, outside of linking to this comment.

brudgers 14y ago

Bad estimates are bad because they don't meet the requirements, not because they are inaccurate. In some corporate cultures, a bad estimate is one that says that The Plan is unrealistic. Other times, management wants a best case estimate (which will be modified based on historical inefficiency) and bad estimates would include ones in which the estimator accounted for normal pessimism. On the other hand, if one is seeking an accurate estimate and A and C are part of the critical path, then they must be accounted for by the estimator. "Shit happens" isn't an excuse for an inaccurate estimate, a good estimator accounts for it.

ThomPete 14y ago
But you can't define your way out of the problem. Meeting the requirements have nothing to do with what it takes to meet them. Two very different things.
- brudgers 14y ago
  The grandparent comment used the term "bad estimate" without acknowledging that the only thing which distinguishes a bad estimate from a good estimate is that bad estimates come back to bite you. My post indicated that the ways in which estimates come back to bite varies based upon the reasons for estimating in the first place, e.g. when the context is "it takes as long as it takes" there isn't a reason to estimate. The first set of estimates I describe are those in which the estimate comes back to bite you before the work has begun. An example would be an estimate within a publicly traded company which conflicts with the information provided to Wall Street, i.e. the purpose of the estimate is to confirm that all is well so that management can collect their quarterly bonus based on stock price. In another life I participated in those. The second group of estimates I describe are created to allow management to apply a single big picture fudge factor to account for big picture inefficiencies, contingencies, and information flows such as those which arise from external contracts. When management asks for a best case estimate in good faith, it is uncommon for the inaccuracy to come back to bite the individual providing the best case estimate. The inaccuracy is known going in, and the final estimate is of the third type I describe...i.e. it attempts to account for "known unknowns" and even "unknown unknowns." The third category of estimate is the only one for which people should be held accountable in regards to accuracy, and any accountability has to be related to the experience and authority to allocate resources of the person preparing it. Treating accurate estimates as impossible is a cop out. They are done all the time. It just takes experience and feedback and a desire for improvement.
  - ThomPete 14y ago
    I know companies who are good at estimating because they never change how and what they give a client. The designers are forced to design for the CMS. If all you need to do is to change things then yes it's possible to project fairly accurate. But in most cases where time estimation matters you can't just use past experience to estimate how much a new project is going to take you. Those are projects where you are innovating/creating/defining a new solution. So calling it a cop out is seriously underestimating the problem and discussion where it's most important not to.

wildmXranat 14y ago

Aaaaannd that's how people learn to cover their track and responsibility by shrouding each step in mountains of process controls and unwritten ^shudders^ protocols. Mind you, just sending straight to production isn't a panacea, but I couldn't help but laugh all throughout reading of the article