UML: The Positive Spin

Finding a use for UML

Obviously the UML will not be useful to any software developer. Could it perhaps be useful to someone else? Project managers, perhaps? Company executives? The companies themselves? Of course not. Indeed the documents make no pretense of such usefulness, and for good reason. It is hard to imagine what benefit a business could get from pages of cryptic diagrams about hazy properties of a poorly understood system.

A friend who was at an object-oriented conference recently told me of all the UML jokes that O-O experts -- some of the most respected people in the field -- were trading during the breaks and in the back of the rooms. He couldn't believe the contrast between the public hype and the private disparagement. But CEOs and other decision makers only hear the hype; they are told that UML is object-oriented, or more often that object-oriented means UML. When it fails to help their software development, UML will give a bad name to the whole O-O field. Given the marketing blitz around it, UML, by not delivering on its promises, has the potential of delaying the progress of object technology by ten years.

The reason I did not discover it earlier is that it only appears in the conclusion. A strange place to describe what one was trying to write about all along, but better than no place at all. Of course what I found is not a technical goal (UML, as I said already, serves no software-related purpose whatsoever, and that's fine with me -- some people have better things to do with their lives than trying to improve software technology). It is not a managerial goal, at least not for people managing software projects. It is not a business goal, at least not for any business using UML. But it is a goal.

When I finally discovered that goal, I was almost driven to tears by the authors' noble and generous spirit. It would be unfair to say that the piles of UML documentation are empty of any substance, when in fact they contain one genuine idea. I found it in the very last paragraph of the very last report describing the 0.91 revision [2]. There it was in all its openness, explaining everything I had theretofore misunderstood in my youthful naiveté. How could I criticize the method for not helping software developers or managers, when it does not care about software development at all, but only about developing a market for consultants and trainers? Everything started to make sense: the complexity and bizarreness of the notation, which I had foolishly taken for a deficiency, are in fact among its most attractive qualities, since they make for endless business opportunities, for Rational and perhaps even for others as well; so does its lukewarm adoption of object-oriented ideas, since it means a consultant does not even have to like or understand object technology to profit from UML.

My long search had not been in vain. It had led me to a full appreciation of the UML, this admirable self-feeding machine, devoted from A to Z to the creation of a new market, free of any of the difficulties associated with the unpleasant business of software development: UML books! UML courses! Courses on the books! Books on the courses! Books on the books! Introductory courses to prepare for the advanced courses! Courses for those who teach the courses! Revisions! UML journals! Conferences! Workshops! Tutorials! Standards! Committees! T-shirts! The more you think about the possibilities, the more dazzling they look. And for any reader brave or bored enough to read the documents to the end, the grand scheme is all there, laid out in the final paragraph.

Reminds me of Amway, Rich Dad Poor Dad.