I just finished reading up on this post from littletutorials.com. Most of these 13 points summarize what I absolutely despise about UML. I had been using UML in one of its early incarnations back in college. I used it once for a small project involving used cars. I used it not because I liked it, but because I was forced to use the damned thing. In college, I used it for my thesis project to “communicate my ideas using a generic, standardized set of symbols”. I used it for the project because my employer needed to see what was going to be done for his site. He already knew SQL and some UML.

I hated it back then, I still hate it now.

For all the 13 reasons the author points out in his articles, I have picked the following reasons since they have directly affected my experience with UML.

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.

All I can say to this is, “Amen!”. The cost of tools depend on the feature set that come with the tools, ranging from $99.00 to $11,000.00+. For instance, IBM’s Rational Rose is by far the most feature packed and the most expensive (AFAIK) $6,000.00 – $11,000.00. As a lone-wolf software developer, where the heck do I get that kind of money?!? I’ve downloaded trial versions of these tools and checked them out. Most of these are Java-based and as most Java-based apps go, they feel kludgy, bloated, sluggish, and out of place on my desktop. They sure as heck don’t feel like the thousands of dollars I would be shelling out if I had to pay for them.

Oh, I’ve tried the free ones as well and the one I really liked the most was ArgoUML.

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.

This is where the author hits the nail on the head. Half of the time I spend discussing the diagrams, I spend it on explaining the damned symbols and what they mean. So instead of trying to communicate your ideas directly to the PHB, you end up trying to explain how the little pointy thing relates to the rounded rectangle thing and why the little stick figure man is getting stabbed with all those arrows.

I found it was much easier to come up with my own set of symbols, containing shapes and symbols that PHB’s are familiar with.

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.

I wholeheartedly agree with this. If I wanted a graphical programming language I would use Scratch. The idea that you can graphically drag and drop blocks code and assemble them into a working system is pretty awesome. In fact I for one would love to have that. But UML is simply not cut out to be a graphical programming language and any attempts to make it so only falls flat on its face.

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.

Again, “Amen!”. This point expands on his second point above. The tools for working with UML are so complex that you need to get some training to get beyond using the basic features of these tools. If this is not a clear attempt to monetize everything about UML, then I don’t know what is.

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.

Exactly! What’s the point to all these diagrams when you frequently have to switch between trying to figure out the diagram and reading actual code? If you’re reading code half the time you’re better off using the other half of your time writing it instead of playing around with diagrams.

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.

I like to call this problem “Tedium ad nauseum”. It’s basically an extension of his 10^th point. Having to switch between code and diagrams to understand what’s going on is one thing. Having to keep diagrams and code in sync is a whole chore in and of itself. It’s tedious. It’s boring. It’s what programmers hate to do.

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.

This is a very good point. UML had and still has the potential to be a useful tool. Not for software development, but for reverse engineering existing code and documenting them. As a programmer, I really hate having to write reams of documentation. Even with all the tools available at my disposal, it’s a tedious and boring chore. Programmers should just program. The documentation team should write the documentation using UML and reverse-engineering tools to assist them in understanding the code.

This entry was posted on Saturday, May 17th, 2008 at 12:51 pm and is filed under Code and Consequences. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.