Death by UML-more
The Death By UML blog piqued my interest. I admit I didn't read the big ACM article.
When I first saw UML, I thought it was snake-oil. I eventually made peace with it when I realized that it was a common notation for describing software architecture. Much like an architect uses standard notation in blueprints, so the builders and contractors know whether a wall should be made of stone, wood, plexiglass, or some other material, UML gives us the elements of a language for describing software architecture. That's clearly useful. I often make diagrams when I'm about to write code--and I think we all do. What connects to what, which object talks to which other object--that's the sort of crucial information that's easily forgotten in a large or ongoing project.
That's important, but it's nowhere near as heavy as it sounds.
The interesting note that "Death by UML Fever" adds is that UML has become not only self-justifying, but the fact that someone has made a UML diagram means that his architecture is somehow blessed. Here's the important bit:
Through no fault of its own, however, UML sometimes does amplify the symptoms of some fevers as the result of the often divine-like aura attached to it. For example, it is not uncommon for people to believe that no matter what task they may be engaged in, mere usage of UML somehow legitimizes their efforts or guarantees the value of the artifacts produced.
I suppose that's not news to anyone. What UML should do, what any sort of architectural language should do, is make it clear whether a particular design is good or bad. Fetishizing UML (stand back, I have a license to kill with literary theory) breaks it, perverts it so that it does precisely the opposite of what it's supposed to do. I think one could argue that fetishizing any technology, techinique, or process, from design patterns to agile programming to RUP to Java itself causes a strange inversion where the fetishized object of desire, having become an end in itself, destroys the end for which it was created. We've certainly seen that with patterns: poorly applied patterns that served primarily to legitimize poor code: "it must be good, it has patterns." "It must be good, there's a UML diagram And look, the code's so complex, you can't understand it without the diagram. Great stuff.." UML, patterns, and our whole artillery of tools and techniques, are only means to an end; code is good because it works, because it's maintainable, because it's efficient, and for many reasons, but not because it applies the principles of some holy writ.
I was going to close this article by saying "kill the sacred cows", but that's not the point. The problem isn't the poor cows; it's that they're sacred, but that's hardly their fault. UML isn't the problem; the step in which UML starts to transfer a "divine like aura" to anything attached to a UML diagram is. If our tools are going to be useful, we can't take them so seriously.