UML is Brain Damaged

I hate UML. I really do.

I've thinking this for 15 years, and now I must let everyone know that I think that UML is brain damaged. Sorry UMLers, but from its inception, even before UML even existed (in 1995, when it was UML 0.8), I thought it was brain damaged.

For starters, UML is specified... in UML. This means that UML means... whatever UML means, because it is specified in itself. People who know algebra or geometry will be laughing.

UML should be called UMD (Unified Modeling Drawing). Really, since it is not a language, neither in the computer language sense nor in the natural language sense.

People who was working with me, who didn't know object orientation, liked UML, the language (or drawing notation) that would allow them to draw diagrams and then we C++ coders could implement those wonderful designs. Needless to say, their diagrams and ideas had to be redone, usually by just tossing them away and looking at the original problem they were trying to solve and presenting a really straight forward solution to it. No wonder why people who couldn't code liked UML so much. It is the same kind of people who mention that failure and success is just an opinion.

There are no successful projects delivered using UML, and I guess all those people who can't program are hiding behind huge piles of diagrams stacked on the floor. You can laugh, but UML is an energy drain, since there is no way you can prove a design with UML is right nor wrong, therefore it is a waste, because it is open to interpretation. Most successful projects ignore UML completely and avoid it like the plague. This is not coincidence, but a serious decision to make.

Java was not designed using UML, nor it's class library. Still there are no compelling UML design for the Java class library and it has been around for at least 10 years. How come? Nobody can do it or it is found that it wouldn't be useful?

I have another explanation: Wouldn't it be possible that real engineers know that UML is a scam?

Have you ever seen diagrams of design patterns (Java best practices)? There are at least 24 design patterns with name and example code, but all UML diagrams made for them look the same. Would you use UML to document the design patterns you used? I bet you wouldn't, because it would be considered a waste, but then how can you explain your design if you can't draw them? But if you draw them, they all look the same anyway, so they serve no purpose.

UML class diagrams do not show polymorphism in your programs and polymorphism is the key to object orientation. No, using separate diagrams for each polymorphic message is not practical. Why is that so? The 3 amigos... no, not those 3, but these 3, who invented UML were after something else, not after solving real problems. Or maybe they were really incompetent, or a mixture of the two.

UML sequence diagrams do not show polymorphism and break encapsulation. Encapsulation and polymorphism are at the center of object orientation. Why is UML marketed as an object oriented tool if it works against object orientation?

UML use cases are simply escenario-oriented documents, specifying "steps" for the user to use the system, while we know that modern user interfaces (since 1984) are event-oriented, and therefore you can't force the user into any steps since the user selects the steps he wants to do.

Furthermore, Rational was the company behind UML. Where is Rational now? Why their people lost so much momentum?

Finally, Rational Rose was the key product marketed by Rational, but the product was obviously bloated (too big), underperforming (too slow), unusable (hard to use) and buggy (a diagram that extended beyond a page was usually the one you could not save). Maybe it was because Rational developed rose using UML.

The fact that most UML architects can't code is a sign that shows that they don't know what they are talking about, yet they have very strong opinions backed by companies that create UML design tools, a whole ecosystem. Architects should be able to code and give recomendations on how to code, pointing to design patterns when necesary. Doing code reviews and writing code conventions, for example, should be at least 20% of the time spent every day by any serious Java architect.

The UML tools camp disguised itself into the MDA tools camp and obviously joined forces with the dying CASE tool camp of the 80's. For now it seems that their fad has not gained momentum. UML has been marketed even as a BPR tool (Business Process Reingeneering), what a nerve!

You know what, it is good if they gain momentum, since it drives all bad programmers into them. Cool ;-)

Disclaimer: UML is still evolving and maybe in 100 years it will be suitable to capture requirements and model systems. In the mean time you can read a lot about the things you shouldn't do in case you are forced to use UML.