Thing is, the core elements of UML are very useful in communicating a design or an idea. Class diagrams are a great way to discuss an OO-ish codebase in front of a whiteboard (or any data model, really). When you do that, it really helps when everybody knows that an arrow in static UML diagram types means "dependency" and not "the data flows from here to there".
Similarly, I still haven't seen a better way to visualise state than with a UML state chart.
It's also very nice if you can draw a UML object diagram that people understand (looks like a class diagram, except you basically draw a hypothetical runtime situation of instantiated classes and you underline the object identifier names). This works best when people understand that the picture on the left is a class diagram (design time) and the one on the right is an object diagram (runtime example) of the same classes. This is not complicated stuff, but it doesn't really work as well when half the team thinks UML is for losers.
Now, bear with me, I'll be the first to agree, UML is a bloated piece of shit. Package diagrams, wtf, who needs that? Use case diagrams that show which use cases are specified, instead of how the use cases go - seriously? Activity diagrams so you can draw a 5-line method on an entire sheet of paper, big fucking what the hell were you guys thinking?? Why do I even know what this stuff is? What a waste of time - even the decent diagram types have 60% bullshit syntax and only 40% useful stuff. And message sequence charts are nice enough for protocols but impossible to draw right.
But to dismiss UML just because some enterprise architects went a little overboard in 2002 is a bit like dismissing all of OOP because 15-level inheritance hierarchies used to be hip.
I wish we could agree on a tiny subset of UML that actually makes sense, and all learn that. This post makes a good start for class diagrams, although IMO even the ball-and-socket notation is overblown nonsense from a time long gone. Maybe we should do this, and give it a separate name.
On a mildly related note, one thing I like about OOP is that you can draw pictures of it easily. Does anyone here know of a good way to visualize functional code structure? You can draw a dependency chart of modules of functions but that only gets you so far.