It may not be cool, may never have been cool, but I’m still pleasantly surprised whenever I come across someone who’s used UML well to document parts of their p

It may not be cool, may never have been cool, but I’m still pleasantly surprised whenever I come across someone who’s used UML well to document parts of their project and by using it well has made things much easier to understand. But using UML as the only documentation or using UML badly is just terrible and a complete waste of time… and it’s all too easy to use it badly. So UML may not deserve it’s terrible reputation… but it has earned it. Edit: It’s worth noting that parts of UML are better than others. Lower level stuff like sequence diagrams, activity diagrams and state machine diagrams tends to be used better in my subjective experience. Generally speaking I find the “Behaviour Diagrams” to use the UML terminology, are the most useful parts of UML and the parts I wish people would consider using for the sake of standard easy to work with data exchange. The UML “Structure Diagrams” (the other half of UML) is what I find people are usually thinking of when they talk about UML in general practice and these are the shittier ones that people tend to have the bad memories of hashing out in long boring management meetings and people making unfounded claims about how magic software from IBM and other giant consulting firms will somehow turn these diagrams into code automatically if the diagrams were somehow perfect enough.