The complete overapplication of UML for many years gave UML an undeservedly bad name. The top comments in this thread are testament to that: many programmers are simply all too happy to go &quot;haha! UML! that&#x27;s for enterprise losers in suits who prefer paper over working code!&quot;<p>Thing is, the core elements of UML are very useful in communicating a design or an idea. Class diagrams are a <i>great</i> way to discuss an OO-ish codebase in front of a whiteboard (or any data model, really). When you do that, it <i>really helps</i> when everybody knows that an arrow in static UML diagram types means &quot;dependency&quot; and not &quot;the data flows from here to there&quot;.<p>Similarly, I still haven&#x27;t seen a better way to visualise state than with a UML state chart.<p>It&#x27;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&#x27;t really work as well when half the team thinks UML is for losers.<p>Now, bear with me, I&#x27;ll be the first to agree, UML is a bloated piece of shit. Package diagrams, wtf, who needs that? Use case diagrams that show <i>which use cases are specified</i>, 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.<p>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.<p>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.<p>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.