Many software projects fail because coders/managers do not actually understand what problem they are really trying to solve. UML in theory, but typically failing in practice, tries to address this. Pour in plentiful use cases and some eye of newt and out pops (not unlike from the Finite Improbability Generator) a complete and sparkling model of the problem. In reality, the input is likely flawed and incomplete. The result is a tool that is a dangerous crutch cicumventing actual understanding of the problem at hand, while generating management pleasing (and I'm a manager) pictorial output. Add to that a big learning curve just to grok the syntax, low usefulness to communicate with outsiders (such as marketing people), and high overhead as requirements change or become more clear make for a negative ROI for this tool. It is clearly a fad that needs to go away and make room for some better formalism.
Slashdot Mirror
Many software projects fail because coders/managers do not actually understand what problem they are really trying to solve. UML in theory, but typically failing in practice, tries to address this. Pour in plentiful use cases and some eye of newt and out pops (not unlike from the Finite Improbability Generator) a complete and sparkling model of the problem. In reality, the input is likely flawed and incomplete. The result is a tool that is a dangerous crutch cicumventing actual understanding of the problem at hand, while generating management pleasing (and I'm a manager) pictorial output. Add to that a big learning curve just to grok the syntax, low usefulness to communicate with outsiders (such as marketing people), and high overhead as requirements change or become more clear make for a negative ROI for this tool. It is clearly a fad that needs to go away and make room for some better formalism.