In response to Les’ response:

Back in the days when PL/1 was the cool kid on the block, and projects were measured in the 100’s of man-years, software was engineered. Flow charts and diagrams were drawn and checked, everything was documented and approved, and only right at the end was anything actually programmed. We know this approach today as Waterfall. It is generally accepted to be a poor fit for most development projects. It is however, a very good fit for most ‘Engineering’ disciplines. I’m a Chemical Engineer by training, and I’ve been there (albeit briefly). Generally an engineering project starts off with one or more feasibilty studies, where you make some broad assumptions and run lots of computer simulations of the system to get a feel for which direction to go in. Then you progressively add detail and refine your assumptions until you have a detailed design that can be used as the basis for procurement and construction. You really don’t want to be making big changes during procurement and construction. Lead times for large equipment like compressors can be several months, and concrete only sets once.

How comparable is this to software development? Not much. The closest relative is probably the type of project (1000’s of man years) talked about in The Mythical Man-Month, which are right at one end of the spectrum, and nowhere near the reality of most software projects. Physical engineering disciplines were developed to tackle very specific physical engineering issues, and trying to shoehorn them onto software projects just isn’t going to work.

What we should be doing is developing a spectrum of practices that are specific to our own industry, instead of trying to force it into a mould that simply won’t fit.