In school, UML seemed like a great idea. It wasn't very fun, but it was useful, and if you had a simple class project, UMLs certainly made things simpler if you

In school, UML seemed like a great idea. It wasn't very fun, but it was useful, and if you had a simple class project, UMLs certainly made things simpler if you were even okay at them. When I got my first job, however, there were no UML diagrams. I was saddened to see this. I don't remember if I was surprised, but I was so sure that I would been useful to have a detailed UMI diagram available for studying the codebase. So, as I got acclimated to the codebase, I took it upon myself to start putting together a UML for our existing product, so that training new people would be easier. After spending several days doing this, my opinion or UML changed dramatically for a couple of reasons: 1) Pretty much all of the UML tools out there are not a pleasure to use. Drawing UML diagrams was still infinitely better than using the various programs I tried. But drawing them on anything but a whiteboard wasn't scalable to the size of the project. 2) Once I had the basic classes drawn out, and realized how diverse the kinds of classes we had were, it became apparent that this just wasn't going to happen. A basic flowchart of the application would be equally valuable. The specificity of UML wasn't worthwhile, having a class with 10+ subclasses was a mess. 3) What I did have was hard to see. This goes back to the first point--the tools are not good. When you labored over all the clicking and dragging, you pulled together this monster of a graph that you can only see a small portion of at a time in a given screen. It was easy to get lost. Printing wasn't useful. Ultimately, I only ended up using UMLs when we were thinking about how we were going to build out new features, or redesign stuff. It was a .NET shop building a Silverlight app, so serialization and strict static typing was critical. A decent JSON api would have made life easy, but since the back end and the front end were essentially all the same thing, class diagrams were very useful. So for the 2 or 3 times that we had to develop or redo class serialization while I was there, it came in handy only for working on small 2-5 class models. That brings us to the next point: do class diagrams have a place in an increasingly dynamically typed world? Functional programming in javascript. Frameworks that have their own detailed class system, or which aren't even class oriented. UML has essentially become analogous to cursive. You learn about it early on, and its important to have a notion of how to read it. But ultimately, since we don't use it every day, we basically never use it.