Right. The problem is that formal UML diagrams tend to be part of formal documentation - i.e., outdated from the moment they are saved to disk (unless they are

Right. The problem is that formal UML diagrams tend to be part of formal documentation - i.e., outdated from the moment they are saved to disk (unless they are used for reproducible code generation, in which case.. good luck). Informal UML diagrams - dynamic box-and-line relationship diagrams scrawled on a whiteboard where one arrow has been drawn in extra thick to emphasize a point; sequence diagrams where one colleague has drawn the sequence arrows as they work today and another has scribbled over the top the arrows as they should work in a different dry-wipe color; those are an appropriate use for "sort-of-UML" - as tools in rapid communication of ideas. My phone's full of photos of that kind of UML. But at that level of formality, nobody should mind if you get the open or filled diamond arrowheads wrong, or you use arrows for one to many relationships instead of inheritance, so long as everybody working on the diagram understands what is meant in that moment. UML is a formal standard for back-of-the-envelope doodles, and that is exactly as ridiculous as it sounds.