There are parts of UML that are really useful: Class diagrams, sometimes sometimes sequence diagrams (I hate them but for protocols they make sense) and most importantly use-case diagrams. But they are not really for writing down a good design, they are tools for brainstorming.

When you wanna flesh out a data structure or model it helps to sketch UML class diagrams on a white board. White boards are awesome tools (get one if you don”t own one!), you can modify stuff, add colors, do whatever you need to help you think. UML is a simple enough structured way to note things in a class diagram.

The same is true when you try to really understand something you need to model that you are not familiar with: Draw use cases to a white board just as a helper to structure your own thoughts.

UML can you help to think because you can keep things on a white board or a sheet of paper: You don”t accidentally forget something important.

But the class hierarchy and structure you write down is not really a representation of the code you will write: Some of the classes you outlined might find their way into your code but others might be dropped or replaced, that”s what brainstorming material is for: To give you a base from which you pull the stuff that you really want to have and drop the stuff that might have sounded like it makes sense but that actually does not.

UML is not worthless, you can see UML diagrams pretty much all the time on the white board next to this keyboard. I even use UML to model/brainstorm non-techy problems. It”s a great tool to support one”s own thoughts.

Apart from that a very abstract UML “class” diagram can be useful for documentation. Why did I put ” around class? Because a diagram of the classes of your system is often quite useless.

When you use UML to document your software you have to realize something: Incorrect documentation is worse than none. So the more detail you put into your diagram the more work you”ll have to keep it current (which makes the diagram a chore that will be dropped asap). When you diagram shows an abstract view on how parts fit together and what abstract parts make up your software it can actually help people understand. Then they get the real information from the code or the associated documentation. UML offers a good way to present overviews.

So UML is not worthless, it can be really useful and is a tool that any person should have (well not UML in specific but just a structured way to represent your thoughts on paper that is good enough that you know after a while what it means).

This leads us to something that people consider to be problematic about UML: Yes, it”s often quite vage and open for interpretation. But you use it just to support your own/your group”s thinking process and as long as it”s good enough that you understand what it says after 2 weeks it”s as good as it ever needs to be. Because it”s not supposed to be a limited graphical programming language. That spot is already occupied by Visual basic. And we don”t want to have two visual basics in the world, right?