* Mistaking UML as a programming language (see, we can write all our software in UML!)
* Code generation (see above, except you still have to write all the code since all you got was a bunch of empty interfaces)
* The One True Technical Artifact (all you need for design documentation is a big tangle of UML!, for which the source file is lost to time and can thus never be updated)
* Satisfying managerial dictates (OK, we'll hack out some not-very-accurate UML diagrams since management says we have to, which is worse than useless--it's misleading)
* corollary to the above: The Enterprise UML Repository (commit one or more of the sins above, plus you're forced to use substandard tools and platforms!)
Good uses of UML:
* Explaining someone else's spaghetti code after you've hacked your way through it
* Explaining your own spaghetti code that was forced out the door before you had time to clean it up
* Explaining justifiably complex algorithms and architectures
* Illustrating important design decisions
* Communicating overall architecture to executives and new developers
* As a common whiteboard language when sussing out technical and/or architectural issues
Note that all of the good uses are all communication tools, only barely design tools, and definitely not programming tools. +1 for UmlAsSketch above.
<small>(PS please tell me someone is working on list formatting for news.arc...)</small>
At one point I was evaluating open source UML software for creating an overall diagram of our project to aid in understanding all the different moving parts at an overview level, but found most of them lacking. Especially in the area of generating UML from existing code.
Does anyone have a suggestion for software which better fills the project comprehension/overview role?
No, but it does have its uses. I've found it particularly helpful when communicating complicated technical decisions to non-technical management. They "feel" like it's a true technical document (even if it only superficially conveys what's actually happening) and it empowers them to make better decisions.
Amongst actual technical staff? I don't think I've ever even seen a UML diagram on display in my entire career outside of perhaps the occasional E-R Schema model.
Honestly, that gap is one that really does need to be addressed since technical staff pretty much work on whatever they want to work on, master design documents be damned. Perhaps some of it is that extant architecture methodologies are all top-down, where information concerning design and intent flow down, but there's no formal feedback loop, a bottom-up component, in-place for implementers to say "well, that doesn't make sense, we're going to do it this way, change the design docs to reflect". I think it's this lack of a formal approach from both directions that really cause a lot of large systems engineering and integration projects to end up with poor results.
Many "technical" UML users I've come in contact with tend to be a decade or more removed from the actual technology they are designing around...familiar only with feature and capability lists of the technology ecosystem they are working in. In management meetings they'll continue to pull out year old UML diagrams built in a vacuum to make a point, when all they have to do is talk to the most junior developer to see that the de facto picture is wildly different than in the docs.
In the end, all that really matters is that the system does what it's supposed to do, it doesn't matter as much how it actually does it. UML makes non-implementers think they are having some say in how things are to be built when it's very rarely the case.
Another interesting thing I've noticed is that as time has progressed, in order to become more useful, the UML spec has started to vacuum up other traditional diagramming techniques beyond just use cases event models. This is definitely an effort to make UML "work" for technical folks and not just decision makers. Unifying/Rationalizing higher level models with lower-level technical models is actually pretty hard and demonstrates a large number of problems with both sets of models pretty quickly, faster than cranking out half-baked code.
I will say though that I've started to see better models for communicating architecture to management recently. Archimate springs to mind: http://en.wikipedia.org/wiki/ArchiMate
It leaves out lots of details that are irrelevant/dangerous for decision makers to see, while focusing them on the entire enterprise stack. I believe it's not part of the newer TOGAF frameworks.
It makes sense for larger organizations where you might not be able to interact with the person who drew the diagram. A formalized diagram is less ambiguous than a more informal one.
I actually didn't mean to imply that there aren't situations where something like UML can be useful e.g. documenting business processes.
However, my own view is that as you actually get closer to code the benefits of the "UML as blueprint" style of thinking become less obvious to the point where they actually can hinder a lot of projects (e.g. artificial distinctions where you get "architects" who only create UML and through it over a wall to "coders" who attempt to turn these designs into working systems).
That's not really a complaint against UML. I'd be equally (if not more) disturbed by an office where "architects" only create informal diagrams and throw them over a wall to "coders".
However, that doesn't mean that UML can't be beneficial when used properly. For instance, I could see using UML as a reference rather than a guide (especially if it's auto generated). I've worked with codebases that I wish had a "map" that I could look at to get acquainted with them.
I often draw diagrams, but they never conform to any formal standard and are very much in the "UML as sketch" mode:
http://martinfowler.com/bliki/UmlAsSketch.html