I am sure that a lot of u have seen the TV-show Mythbusters on Discovery channel. If not, u might want to have a look here  

The purpose of the show is to "bust"or "prove" a story almost everybody knows and assumes or may be hopes to be true. Like "Can you survive a falling elevator by jumping when it hits the ground?" ... or ... "Was the Ming Dynasty able to launch an astronaut?" ...or ... "Can you swim as fast in syrup as in water?" ...  

In our IT-profession we also have myths like the story of the new tool where every project achieves a cost reduction with of at least 30%. Or the story of the Engagement Manager who thinks that managing an IT-project is similar as building a bridge. Or the story that implementing a package is more cost effective than bespoke software . 

But the most persistent rumour is no doubt the one of the Standard Method. And with a method I mean things like RUP, Scrum, ASAP, OUM, OpenUP. Or may be you prefer control-methods like Prince2 or CCPM. And in this case with a method I mean the fullblown thing with all its techniques and sometimes tools. Almost half a century ago, the first method originated from some pretty chaotic projects. Soon the engineers in these days discovered that it was better to design things first and, after building the software, test it before actual implementation. And, may be it was better to create a plan first, report some progress frequently and evaluate when finished to capture some lessons learned . Well, I admit that this is not really rocket science  but how come that everybody seems to talk about methods and tools more then about the actual construction of a good piece of useful software?  

Well, you might have read my article about languages. Talking about and re-designing methods is just as human. And everybody thinks that their method is better then others, better suited to the specific technology, better for the circumstances, better suited to the problem, or better . . . . In fact RUP is probably the best effort to create something like a framework in stead of a method. Too bad only a few people see the relevance of the difference causing further confusion on our flat IT-world (yes, we're still before the "Enlightenment, the "Age of Reasoning" ).The point is, the "method-inventors" are probably right. All of them. Everybody started off with a very good solution for a specific problem. The problem however is that there is no issue, business, technology or functionality so isolated that only one approach or method can fix it all. At its best, using only one method simplifies the workflow and reduces risks but in almost no situation, except the very simple ones, using only one method delivers the cheapest and fastest route to success. Coming back to the quest to find the Holy Grail, the Standard Method: as I said earlier in methods, we wouldn't have called the project plan "The Plan of Approach" when the approach was always the same! Would we? Imagine my favourite example: a typical future project is about an Open Source infrastructure with an Oracle database, SAP back-end, Microsoft front-end and office tools, Ruby/FLEX web-services. Some functionallity is very well known, some have to come into existence with trial and error in the real world. What Standard Method are we going to use for this? Only a very good methodology-framework with enough respect for differences in people, processes, technology and alternatives on technique-level (different professional angles to create an artifact) to create an unique workflow (the approach) can cope with this. Well, I guess we have to see that the world is round first .So, the "Standard Method"? . . .

  B U S T E D !!!

Be first to comment this article

Write Comment
Name:
Comment:
Code:*