Creating a bunch of UML diagrams up front is usually the sign of a broken software development process. However, there's a lot of great work that went into the

Creating a bunch of UML diagrams up front is usually the sign of a broken software development process. However, there's a lot of great work that went into the various diagramming grammars that turn out to be really useful in different cases. I've found that spinning up UML-like diagrams for certain subsystems on a whiteboard, or quickly in yEd or similar tool helps immensely with: a) creating a "thing" to facilitate communication and understanding b) capturing a design after it's done as part of a deployment/hand-over package c) a useful toolkit for reverse engineering a system that you had dumped on you etc. basically, any sort of ad-hoc communication need or information capture process. Software Engineering coursework will warp your brain into thinking that you need to spend a few years in a spaceship in orbit around Saturn dreaming up millions of UML diagrams that when done, will magically barf out all of the code that makes up some enormous over-engineered enterprise fizzbuzz system. It takes a long time to overcome that nonsense without throwing away the goodness that exists here -- there's some excellent diagramming techniques that really help with coming up with a common understanding of how a system should work for a team and product owners and used well can bridge huge communication gaps. Many of the diagrams more or less show the same information, but with a slightly different angle that can help communication. The diagram grammars themselves can get really fussy and particular, but I think when they're used best only certain components of the grammars are used to fill very specific communication needs, the rest is more or less sketched in, and the remaining grammar can be pretty comfortably be left out. Many times, you can just invent a diagramming grammar that you can the other parties agree to and just "be inspired" by ideas from UML and get most of what you need done. There's also grammars that are not part of UML that would make sense for people to get familiar with. ArchiMate comes to mind as a particularly great example. I don't use it explicitly (the software tooling support for it is garbage, but you can fake it with yED pretty well), but I've used systems inspired by it numerous times to succinctly capture incredibly complex enterprise systems and data flow and tie those things to business processes and needs. https://en.wikipedia.org/wiki/ArchiMate https://en.wikipedia.org/wiki/ArchiMate