Then yesterday I was talking with someone who is helping dig out a project that has been driven into the ground by some people with very firm beliefs about how things should be done these were people who had taken pieces from agile, from waterfall, from TOGAF, from lots and lots of different places and combined it in their own approach.
This is alternative engineering in practice. The approaches were often contradictory, so they had a waterfall process but they didn't do full requirements up-front as the development would be agile. The Architecture wasn't complete and certainly didn't include the principles or non-functionals, but did include the hardware infrastructure that the solution should be deployed on.
When challenged on this it was described as taking "best practices" from lots of areas and combining it in a methodology which "best suited the company". This wasn't however like the start of a RUP project where you decide which RUP artefacts are required, it was just a complete and utter hack by people who wanted to do certain things, mainly the easy or interesting things, without doing the difficult or boring bits.
Around the industry I see Alternative Engineering practised a lot. Sometimes it evolves and is tested, made robust and clearly documented and becomes Engineering (SCRUM for instance), other times it remains vague in the vast majority of cases with people referring to a very limited set of successes and ignoring a huge amount of failures (step forwards XP).
The point is that Software Engineering does move on. The Spiral killed the Waterfall, at the stage that this happened then Waterfall became alternative engineering, in the same way as people thought that "nice smells" would ward off plague became demonstrably false so Waterfall for the vast majority of software development programmes became nonsense.
Iterative development then evolved from the Spiral and became undoubtedly the best way to deliver software. Agile added some dressing around the edges, some good some bad but the basic principle was still iterative development.
Alternative Engineering is what most IT organisations appear to practice. They don't go and look at what has been proven to work and they certainly don't accurately measure their own processes and ensure that they are working effectively. Their ability to learn is practically zero but their ability to have faith in what they are doing being the right way knows no bounds.
Cargo Cults are at least trying to copy people smarter than them, they are clearly practising alternative medicine but they are doing it by pretending to be proper doctors. Most people in IT are nothing more than quacks who don't, can't and won't prove they are working in better ways and hold on faith that their unique "blended" view and methodology which they are the only people on planet earth using is clearly the best way.
Sometimes these organisations can be broken out of the stupor and made to work in new ways which actually work. Its then always impressive watching the level of religious fervour that can develop as they turn on their previous ways and driving whole scale change. Unfortunately they then often apply this new way to places that it should not be used (Agile on Package implementations for instance). The Alternative Engineering practice then kicks in again and the cycle repeats.
The point is that if you aren't actually measuring your performance and understanding how a given requirement will be implemented and how over time your will reduce the time for that implementation then you are also practising Alternative Engineering. If you aren't looking robustly at your development and delivery processes and verifying that they work and that they are proven to work then you are practising Alternative Engineering.
Alternative Engineering is bunk and its part of the problems of Art v Engineering which also underpins the Cargo Cult phenomena. There are a vanishingly small number of people who can practice software as an Art. In my entire career and with everyone I've ever met its probably no more than 1% of people who can do that properly. The rest need to be doing proper Engineering based on the measured implementation of processes that are proven to work.
Surely in an industry that has above average scepticism for "alternative" therapies we should apply the same rigour to our day jobs?
Updated: Found a quote from Fred Brooks that just sums it all up
“I know of no field of engineering where people do less study of each other’s work, where they do less study of precedents, where they do less study of classical models. I think that that is a very dangerous thing”
The man is a genius.