I've been writing software for 20 years, and aside from my employer paying for a course on UML a few years ago when it was all the rage, I have never, ever seen UML seriously used.<p>Not that I've ever worked at Microsoft or any massive "pure software" groups; I've basically worked in "get stuff done" smaller software groups. However, I suspect these small groups are far more common. When push comes to shove, code <i>is</i> the design documentation.<p>Beyond that, I've always had practical issues with UML's need to specify everything. How often is that valuable? Any given box-and-stick-diagram-with-labels is bound to be pretty clear, whether or not it does things the UML way. I would be annoyed if someone wasted extra time (and, likely, money) on a UML-aware tool, when it would have been faster and as useful to just sketch something.<p>I've also tended to rely on automatically-generated-and-therefore-always-correct diagrams (e.g. Doxygen, through GraphViz). This is especially true given that the majority of my documentation, even outside the code, leans toward plain text formats (e.g. man pages, simple text files, reStructuredText, or HTML). My reliance on those formats forces documents to be on the short side, which also helps avoid the risk of inconsistency with the code.