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.
6 comments:
Has Agile (or Iterative Development or Spiral or Waterfall) been "proven to work"?
It has in my world, where requirements are vague and changeable. I used to work on embedded systems where less change was tolerated and technical specs were cast in stone. In those days waterfall was fine.
If you are developing "client facing" applications I have no doubt that "agile" (in my case Scrum) works
Iterative development has certainly been proven to work. Cobb and Mills (IEEE Software Sept 1987, November 1990) cover how iterative/incremental + formal specification adds quality without cost. Fred Brooks in "No Silver Bullet" (which is based on a LOT of research) states that iterative is the only way to deliver.
Iterative has been proven. Agile isn't special (IMO) and some Agile elements aren't proven for large scale adoption (XP) others appear to have more formal measures (SCRUM).
I've updated the post to include a quote from Fred Brooks on this topic.
I believe construction of such projects requires knowledge of engineering and management principles and business procedures, economics, and human behavior.
Steve,
I agree with your sentiments and, as long time sufferer of Alternative Engineering (or as I prefer to call it "New Age IT"), every bit of research is good news in my book. However, I'm not convinced that there is anyway nearly enough of it to say that anything is proven ("The Silver Bullet" only references 12 other papers with is not a "lot"). Maybe the nature of engineering is that experience - that something is shown to work - is the best way forward.
Can we learn anything from other engineering disciplines? For example, in construction does Lord Foster and his team of architects scrum-down every morning when they are designing a new bridge ;-?
Mick said:
"Maybe the nature of engineering is that experience - that something is shown to work - is the best way forward."
I wholeheartedly agree but this isn't just about Agile vs X but ad-hoc poorly justified/reasoned engineering in general.
How do we ascertain that something works?
If we want to answer that question there are some other challenges we need to address first:
(1) What qualifies as success?
(2) How do we ensure we're getting representative data?
(3) How do we ensure that what people say they did to achieve success is actually what they did?
Those will be difficult to get to grips with as most people but particularly introverts (found in large proportions in development efforts) will shy away from concrete measures of success and failure.
"Can we learn anything from other engineering disciplines?"
Sure we can, some of us do but we are a minority as Brooks implies:
“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”
We can see this behaviour manifested in many different ways including:
(1) Experienced (and thus older) people are largely ignored in favour of others that make use of some latest language or technology or are expert in something currently experiencing hype.
(2) Many developers when confronted with a problem don't seek data to justify an hypothesis preferring to wildly speculate and hack on an assumption.
I believe you're asking the right question, as have a few of us including Steve (hence his blog post). I believe we understand the behaviours that cause the problems, fixing them is where we make no progress.
I think this is because we set the bar to entry as a developer far too low. We claim development is art or science (doesn't matter which) which implies there will be a limited number of skilled practitioners, yet the sheer size of the "professional" developer population suggests this natural limit does not apply. Maybe because amongst other things, the vast majority of interviews focus on what technology one "knows" as opposed to discussions about what it takes to build quality software (process, design etc)?
The majority of people involved in the discipline of development are not experts (and that includes the management) or even sufficiently talented. Combine this with some human factors:
(1) Continuing to draw down a pay-cheque.
(2) Keeping things as they are so that (1) holds true.
(3) Appearing expert to satisfy the introvert ego.
(4) Insufficient skill/perception to understand or accept what they're doing is poor.
And the result is little if any progress, limited desire to change, a natural resistance to progress, cargo cults and alternative engineering.
Post a Comment