Good UML is really simple UML.
"Then what about complex things? Can't make everything simple"
Do partial diagrams. Simplify or skip things your team already knows.
Also, great UML is no UML. Sometimes the code itself is short and clear enough, requiring no diagram (of course, not all diagrams are about code... but use case diagrams are rare these days anyway).
Also, use cases and use case diagrams are great.
Also, perfect UML is disposable. Thinking of long term diagrams that serve as documentation is a mistake.
I very much like your comment. It describes practical use of diagrams. In the past, I've included diagrams for a particularly complex state in the comment on top of my code. It certainly doesn't describe the whole system, or even the complete state of that code. And I expect that someone will delete the comment at some point. That's all fine.
Thanks!
I remembered once I drew ASCII diagrams for a particularly tricky algorithm in the top of its unit test methods. And people indeed deleted them.
This is why UML only belongs on a whiteboard. It makes it much harder to include unnecessary detail when you have to physically add it, and there’s hard real estate constraints.
> This is why UML only belongs on a whiteboard.
UML belongs in whiteboards, design documents, and project documentation. I don't know where else people expect to use it. I mean, does anyone expect to generate anything out of a sequence diagram?
I really meant that the constraints of drawing it by hand forces you to draw only what matters