3 ms·
The majority of building projects are simple and predictable - like single domestic dwellings. Building contractors have gotten pretty good at estimating the c
by 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.