13 reasons for UML’s descent into darkness

UML lost the programmers. There is no doubt about it… in my mind. And when a software design technology loses the programmers it fades away no matter what the academia thinks. This happened because UML was pushed in a direction that most code writers don’t like: it started to look a lot like bureaucratic paper work. If we list what went wrong it starts to look a lot like the mishaps of other committee driven technologies like CORBA for example. In random order I can list:

1. Design by committee

This one is very big and usually a recipe for failure in the long term. Just look at CORBA and for a new case at the never ending list of web service standards.

2. The obsessive focus on monetizing UML

Trying to sell expensive tools for a technology that is not mature enough and only makes promises to the management (just express your ideas in pictures and the code will be generated by our magic wand) can only work in short term. At some moment somebody realizes the costs are too big for the benefits. Lots of programmers instinctively hated the whole thing. Others were persuaded by management or by curiosity to try it. Most of them never used UML tools for more than a project.

3. Tries to unify everything even the kitchen sink (UML specs > 800 pages)

When you try to offer a solution for every problem in a domain, in the end you are not offering anything useful for any problem in that domain. UML tried to solve all the issues with software development. My feeling is it just forgot about the “software development” part. Software is used or it can be used in almost every human activity. Trying to capture everything is an impossible task - even at 800 pages, UML covers only a small part of the complexity of software engineering needs. It is too big but still too generic and abstract.

4. Departure from what programmers perceived as the initial goal

As a programmer I liked the standardization UML provided for design related communication. It was great to be able to use a common set of symbols to communicate my ideas to another programmer or designer. I think most programmers still use only the class diagram and maybe occasionally when they write a document the sequence diagram. UML started to go up into the stratosphere with all those business oriented diagrams that even the business people didn’t understand or use.

5. Concept bloat

Trying to bridge UML to reality made it incorporate concepts from all the languages in fashion during the last 10-15 years. Anybody knows how to represent a Java anonymous inner class?

6. Always catch-up with new languages and concepts

In continuation of the above… and because the promised prize was full code generation you have to be able to represent specific language constructs. Closures in UML anybody?

7. UML attempts to become a programming language

By aiming to be able to generate full code actually UML tries to be a programming language. In my mind there is a big problem with a general purpose graphical programming language. In human history the written form of all languages evolved from graphical to textual. Alphabets proved to be more versatile and more expressive than pictures in capturing ideas. Try to describe any simple process in images. The funny thing is you still have to annotate the images with words. And the full text version with no pictures still gives you more details. Pictures prove to be good at sharing ideas and allowing people to visualize concepts. But in the end words are better at describing the fine details.

8. The need for expensive tools vs. just a text editor

The entry level for using UML for more than just informally sharing ideas on a white-board is very high. Tools that are any good are insanely expensive. On top of that they need training as they are not all the time the most intuitive tools. They start to look like a solution screaming for a problem to solve. Consulting companies seem to love these tools since they open opportunities for expensive training courses.

9. Lack of model clarity

Pictures are interpretable. I heard this kind of complaints from programmers trying to understand the design of a system from UML diagrams: you need to read the code to understand what the diagrams mean.

10. Lack of solutions for real software design issues

While the specifications are huge there are no good solutions for problems common in software systems. Quick examples are:

    * No solution for multi-tasking and communication between tasks
    * No dependency between use cases

11. Assumes you can know everything before writing the first line of code

The concept of writing first the user manual and then the generate the code based on it is a noble goal but… probably impossible to achieve. In practice everything is so dynamic, that the maintenance of the UML diagrams so they conform with the reality of the code becomes very fast a chore nobody wants to do.

12. Treat software development like manufacturing

Software design is not manufacturing no matter how much management likes to think about it this way. Software creation is a creative activity so a more accurate description would be craft, art or something along this line. UML tries to standardize and formalize the unknown, the imagination and the talent.

13. UML tools focus on the wrong goal

Most of the UML tools out there promise code generation. This is most of the time useless since they generate just empty class bodies with no logic. It is also cumbersome and annoying because one has to keep the code and the diagrams in sync. Some even use ugly formatted comments as markers.
Another problem with these tools is the amount of real estate diagram elements take on the screen.
I tried many times to look at UML diagrams of complicated systems but looking at only the lower left corner of a class square along with two crossed segments doesn’t help much with understanding.
I think the tools should have focused on reverse engineering for documentation purposes. In my opinion no decent reasonable priced tool exists in this area. Even tools that manage to decently reverse engineer the code do a poor job for documentation purposes since they cannot differentiate between what is essential and what is just noise/boilerplate in the code.
As a result most finished projects that use UML have code that doesn’t resemble at all the nice UML diagrams drawn at the beginning of the project.
In general I don’t think code generation is a good idea. Usually what can be generated is repetitive code and most projects would be better off with that common code implemented in a library and called from there.

In the end as a conclusion I think UML had a generous idea to bring software designers speak a common language. But this idea got lost on the way for economical reasons. And when the value is lost the customers leave.