Okay, here goes my first real post.

Every developer must have at least a basic understanding of UML. In my opinion, it can be a very powerful tool for explaining the architecture of applications (even to yourself after not having worked in the code for a while). It’s much more easy to follow a neat diagram, than to have to dig through the code and go from method to method, switching between classes and trying to remember where in the whole application(flow) you are.

A downside of UML is the fact that we as developers like to work more in code than we like making diagrams, charts, documents with long boring texts,… Code is much more fun! To make matters worse, whenever you change parts of the code, the documentation has to be updated too. Especially when big changes have been made, or the updating of the documentation has been postponed for too long, this makes a fun job indeed.

Alongside this, discussions or considerations can arise over futile details which will have no influence on the ultimate goal of UML: clarifying the workings of the application, explaining the architecture in a simplified way. Not all details should go in your diagrams, because they won’t help at guiding a newcomer (or yourself) through the project. Typically, class diagrams are stuffed full of methods, properties, members, associations, … which sort of clouds the overall image. Read the interesting article on analysis paralysis (don’t forget part 2).
Put this all together and people start thinking UML will hold them back more than it can help them. And it can and should help! Just put enough time into it, without putting too much time into it.