Does UML bring Value?
Recently I rediscovered an old study exploring the use of UML in the real world: UML in practice (external link)
It was previously linked in the UML article of the English Wikipedia, but has since been removed and can only be found in the history.
The study concerns itself with if and how programmers use UML. To make a long story short, UML gets a pretty big smack-down. I admit, the sample size of 50 informants makes the study somewhat less representative than it could be, but I see no big difference to software development I have observed in my own development history. I will add some commentary to some of the statements made in this document.
In my humble opinion there are two distinct ways to generate UML: Complete and partial. "Complete" meaning you try to create the diagrams to reflect on how the software actually functions, "partial" meaning you try to convey the idea of whatever it is you are programming. The complete approach has two major drawbacks. First: As mentioned in the study the detail of the diagrams makes it incomprehensible, if not for the developers, then for everyone else.
Second: Making implementation-specific decisions before you have even written one line of code, before you have even an inkling of what the hell you are doing, is a recipe for disaster. If you are lucky you will get the opportunity to create a prototype, but even then it is probably best to keep some significant flexibility, as the finished product is most likely still going to be adjusted, and with "adjusted" I mean every feature known to man will be added with reckless abandon, completely irrespective of the original scope and architecture.
Besides all of this there is the often neglected issue of humans themselves. Programmers aren't stupid and are going to make some very simple calculations: If a programmer modifies the code and has to do manual changes to the diagrams, he is less likely to want to do any significant changes, as the size of the change correlates almost one to one to the amount of changes on the UML documentation, once the change is significant enough to change (parts of) the overall architecture. Obviously this problem gets worse the more granular the UML diagrams are. Try to automate this and you are going to have way too much detail and the diagrams will be useless. Filling up your plate too much is going to make you lose your appetite. This has nothing to do with bad software practice but accepting humans as what they are: humans. Unless you are a masochist you will try to avoid pain and UML is right between getting kicked in the nuts and getting a root canal.
Value Judgment
Is there then a place for UML? I had considered writing a long essay comparing the pros and cons, but I decided against it, as I struggled to come up with even one positive feature or concept, but could think of many negatives. The worst thing I can say about UML is that it is ugly. Really, really ugly. But, I hear you say, isn't the tooling separate from the spec? Yes, and every single UML tool I have come across is hideous. An argument might be made that aesthetics have nothing to do with quality, but I disagree. Just like in coding, if whatever it is you are looking at is an ugly mess, it is very likely incorrect, simply because your brain doesn't want to look at it more than absolutely necessary. A good diagram, a concise explanation, a well executed piece of code is something like a well constructed bridge - a thing of beauty you look at over and over again, marvel at its structure and frame, but take note of what can be done better the next time. UML wants to make you quit every step of the way.
On a side-note the best UML "tool" is actually PlantUML, which is basically a text file in which you write a block of text to describe what should appear in a generated UML diagram. Even then it takes the OpenJDK JVM of the official PlantUML jar several seconds to generate an image from 20 lines of text. Basically the best UML tool is something which does not have any graphics whatsoever. I admit this may actually have more to do with the horrendous UML tooling (There are actually some PlantUML plugins for various IDEs I have seen, which seem to work quite well).
A Professional too
I understand the impulse to use UML. Look at us guys! We're professionals too! We have diagrams and floor plans like architects, we have logical operators like those mathematicians, we are a real profession, really! Of course we are a real profession, and UML has nothing to do with any of it. I would think the amount of money made by software development speaks for itself, but I suppose people can only see value in living if they get a pat on the back by people who don't know a single thing about what they are doing and couldn't care any less.
The customer too will be anxious and demand the use of professional tools. Isn't the abandonment and failure of software projects the common occurrence rather than the exception? Doesn't the customer need some assurance? Don't we owe it to the world, nay, humanity, to finally get our act together and "engineer" software the right way, Test-Driven-Development, docs before blocks, engineers' promise and so forth? Well, I suppose so - I just question if these assurances, including UML, will result in a higher chance of success.
One Tool to rule
UML's scope is too broad. The issue is already in the name: Unified Modeling Language. Not specific modeling language. Not class modeling language, or use-case modeling language. Unified - one size fits all. Yes, UML has different diagrams for different use-cases, but why? Well, because one size does not fit all. But if it has different diagrams for different stuff, then the question is what's unified about it? That it stems from the same committee?
No, UML doesn't bring any value compared to other things a developer would have done anyway, if UML didn't exist. Aligned boxes/circles, text and arrows will do the trick just fine.
I am still open to modeling languages. One way to convince me is to drop the unified.
Addendum: In the original article it was stated that UML was the "Universal Modeling Language" instead of the "Unified Modeling Language". The same reasoning applies to "Unified" instead of "Universal", as in practice these are one and the same. I just changed the Universal to Unified and the reasoning stands just the same.