I'm distrustful of people who make lots of diagrams; it indicates to me that they may not actually know how to create the thing they're drawing, and thus lack t

I'm distrustful of people who make lots of diagrams; it indicates to me that they may not actually know how to create the thing they're drawing, and thus lack the capacity to make truly sound decisions about it. I've found UML-y diagrams to be useful it a few cases: 1. When sketching out an object model in a statically typed language, it helps to see the whole thing at once. The class diagram tool in later versions of visual studio is a nice compromise between functionality and usability for this case; it's easy enough to generates the code, but it's easy to ignore the diagram and do real work when you're ready. 2. When talking about system interactions with people via email, sequence diagrams can be useful. http://www.websequencediagrams.com/ http://www.websequencediagrams.com/ is by far the fastest and easiest way I know to make them; trying to use a GUI tool is an exercise in frustration. 3. If my system has some internal structure I want to draw for people, I output graphViz data and let it draw the picture for me. Pictures generated in this way are always up to date. I don't know that I've EVER kept a diagram around as a piece of documentation; they're invariably wrong after a short amount of time. In fact one of my favorite things about the visual studio diagrams is that they break if you change the code out from under them.