4 ms·

Building projects are a terrible example of predictability. They are ultimately highly agile due to dependencies on inherently unpredictable factors such as wea

Building projects are a terrible example of predictability. They are ultimately highly agile due to dependencies on inherently unpredictable factors such as weather, 3rd party suppliers, industrial disputes, archeological discoveries, legal disputes and so on. The difference with software is that if you have done it before you should have automated it. The great majority of programming is therefore design work. There is an answer here which is reversing the problem and simply timeboxing based on expected ROI and there is certainly no need for task estimation as a component of fixed price bidding, particularly where that has a lousy historical track record and wastes client money. (I'm well aware that on many very large projects this is not the case and they are run like an old-fashioned production line with humans performing well-defined tasks - but this only illustrates the huge inefficiencies, lousy processes, and general ignorance of software development practises as standard in SI's.) But aside from all that, how do you account for http://en.wikipedia.org/wiki/Planning_fallacy http://en.wikipedia.org/wiki/Planning_fallacy ? I'd also be interested in how you apply cost estimation to debugging and other BAU tasks.

derriz 12y ago
The majority of building projects are simple and predictable - like single domestic dwellings. Building contractors have gotten pretty good at estimating the cost and time (or else they go bust quickly) to complete a family home from scratch on an already serviced plot despite all the dependencies and unpredictability you describe. Applying "agile" (i.e. not doing requirements gathering/careful estimation/detailed planning and not having a clear goal at the start) would be a recipe for going bust very quickly. And the majority of development is (despite our egos) as mundane as this really. The effort is certainly NOT spent on design work; have you ever quantified the effort that goes into various aspects of delivering working production software? Re. planning fallacy, what of it? It doesn't make estimating impossible; once you are aware of it, you account for it in your estimates. You also calibrate your estimates with independent models and with empiricism (i.e. previous experiences). But the literature is extensive on this topic - I can't give a summary here but if you are interested, there are worse places to start than with Boehm; deeply unfashionable I know but built on (shock! horror!) empiricism and not the rationalist (in a epistemological sense) sophistry which dominates the thinking of "agile visionaries". Really it's like we've regressed to a pre-scientific age in the field of software engineering processes. Most of the debate seems about as relevant as arguing about how many angels can dance on the head of a pin. It seem actually observing and measuring reality went out of fashion sometime in the 90s.
- dreamfactory2 12y ago
  > The majority of building projects are simple and predictable The waterfall approach you are advocating can work on simple projects and indeed it's how most digital agencies operate. However it starts to fall apart at the seams precisely on large enterprise projects and it's no coincidence that agile came from experience on these kind of large projects. It's worth noting that the proponents of agile and post-industrial approaches are not '20-somethings who don't know how the real world works' but people with extensive industry experience such as Alan Cooper. > The effort is certainly NOT spent on design work While I'd certainly agree that there is a lot of boilerplate and wheel reinvention out there, that does not represent effective development. Software development by definition is the practise of creating automation. The mindset of much non-technical management today is frequently one of Henry Ford era industrialisation whereby processes are designed and carried out by developers in a form of mechanical turk model - for example just about any large scale outsourcing project. However, if you take a look at a car production line today, that human work is automated and done by robots in darkness. Efficient software development is supposed to look like this - the developers designing and creating the production line itself, not manually creating the end product. We see this better use of human labor and subsequent raising of the skills bar reflected in the job market with demand shooting up for all kinds of design roles, from architect to UX. > Re. planning fallacy, what of it? It doesn't make estimating impossible; once you are aware of it, you account for it in your estimates That's the whole point of the planning fallacy - it occurs even when we take it into account. There are supporting studies here and it's simply incorrect to say that this is non-scientific. > It seem actually observing and measuring reality went out of fashion sometime in the 90s. Are you really advocating that time and motion ever turned out to be effective at growing or even saving businesses? But seriously, agile delivery tends to be associated with an excess of observing and measuring if anything.

derriz 12y ago

The majority of building projects are simple and predictable - like single domestic dwellings. Building contractors have gotten pretty good at estimating the cost and time (or else they go bust quickly) to complete a family home from scratch on an already serviced plot despite all the dependencies and unpredictability you describe. Applying "agile" (i.e. not doing requirements gathering/careful estimation/detailed planning and not having a clear goal at the start) would be a recipe for going bust very quickly. And the majority of development is (despite our egos) as mundane as this really. The effort is certainly NOT spent on design work; have you ever quantified the effort that goes into various aspects of delivering working production software? Re. planning fallacy, what of it? It doesn't make estimating impossible; once you are aware of it, you account for it in your estimates. You also calibrate your estimates with independent models and with empiricism (i.e. previous experiences). But the literature is extensive on this topic - I can't give a summary here but if you are interested, there are worse places to start than with Boehm; deeply unfashionable I know but built on (shock! horror!) empiricism and not the rationalist (in a epistemological sense) sophistry which dominates the thinking of "agile visionaries". Really it's like we've regressed to a pre-scientific age in the field of software engineering processes. Most of the debate seems about as relevant as arguing about how many angels can dance on the head of a pin. It seem actually observing and measuring reality went out of fashion sometime in the 90s.

dreamfactory2 12y ago
> The majority of building projects are simple and predictable The waterfall approach you are advocating can work on simple projects and indeed it's how most digital agencies operate. However it starts to fall apart at the seams precisely on large enterprise projects and it's no coincidence that agile came from experience on these kind of large projects. It's worth noting that the proponents of agile and post-industrial approaches are not '20-somethings who don't know how the real world works' but people with extensive industry experience such as Alan Cooper. > The effort is certainly NOT spent on design work While I'd certainly agree that there is a lot of boilerplate and wheel reinvention out there, that does not represent effective development. Software development by definition is the practise of creating automation. The mindset of much non-technical management today is frequently one of Henry Ford era industrialisation whereby processes are designed and carried out by developers in a form of mechanical turk model - for example just about any large scale outsourcing project. However, if you take a look at a car production line today, that human work is automated and done by robots in darkness. Efficient software development is supposed to look like this - the developers designing and creating the production line itself, not manually creating the end product. We see this better use of human labor and subsequent raising of the skills bar reflected in the job market with demand shooting up for all kinds of design roles, from architect to UX. > Re. planning fallacy, what of it? It doesn't make estimating impossible; once you are aware of it, you account for it in your estimates That's the whole point of the planning fallacy - it occurs even when we take it into account. There are supporting studies here and it's simply incorrect to say that this is non-scientific. > It seem actually observing and measuring reality went out of fashion sometime in the 90s. Are you really advocating that time and motion ever turned out to be effective at growing or even saving businesses? But seriously, agile delivery tends to be associated with an excess of observing and measuring if anything.