UML suffers from false precision. Nobody cares about most of the specific rules and grammar of the language because the output is designed to be generally readable by a lay audience. The time your spend making your diagram compliant with UML is better spent making and remaking good general diagrams.
Also the level of detail that UML demands always turns out to be imprecise once coders end up implementing specs. So it's a place where enough formality is required to be a PITA to model but where it falls just short enough of the specifics a programmer will need once they get to actually building out the product.
I always treated UML as a window into the domain, not as a precursor to the code.
With just a few Use Case diagrams, some class diagrams, and maybe some sequence diagrams, you could communicate what the final system should do and how people will interact with it.
The details of how to implement would be derived from the architecture used. I always found even a few basic diagrams with little detail (classes without fields) very useful and miss them now that people don't want to "waste time".
The idea was if you found that the model was lacking in some way, you would update the model and regenerate your code. In practice that just didn't work, or at least it didn't result in saving any time or in producing better software.
Exactly. Tools to build visually appealing diagrams well appeared. I remember how fun it was diagramming in Visio for the first time.
Why would someone (especially someone non-technical) spend the time to learn and write what's essentially code to make a diagram when the alternative is drag and drop? That's not to say UML is without value, but to me it comes down to the difference between CLI and GUI tools: when the latter is broadly available to the masses, the former is only going to be used by power users who want the flexibility.
Another personal nit: I've never seen a "pretty" UML diagram. The value of aesthetics is obviously not critical, but if I'm looking to make a nice diagram to show my boss and the options are UML and Whimsical, I'm going with Whimsical every time.
I’m of the opposite predilection. I want to be able to manage my architectural diagrams in code review. I like having a tool where I can edit it in one pane and have the diagram be a live preview beside it. Ideally the wiki tool would be able to render it.
GUI tools I find aren’t as good for iteration/living in source control/embedding in a wiki nicely. “As code” ecosystem is very immature - automatic live preview is frequently non-existent, resulting diagrams are ugly and hard to layout.
PlantUML is great but suffers from having a very difficult to customize layout, finicky styling, ugly default style, and a bit of a mess of a language that’s evolved organically.
> Why would someone (especially someone non-technical) spend the time to learn and write what's essentially code to make a diagram when the alternative is drag and drop?
An advantage, depending on context, is that it brings the diagrams closer to the code that they're modeling, making it possible to version control them and include the diagram generation in documentation build automation.
They're not modeling code in many cases, they're modeling processes, products, and user flows. If you're building an app, your diagram is going to look a lot more like the things your users see in order rather than the code to make those UIs appear. E.g., the code for react-dom-router routing is going to look very different from the actual navigation patterns built on it (tree structure versus linear flow).
The primary need for diagrams is drifting further from the use case you're describing.
A software engineering course I once took categorized modeling/specification techniques in three groups: informal, pseudo-formal and formal.
Informal specs are just prose with maybe some diagrams. They are very helpful and not too labor-intensive to produce, so their usefulness is obvious, but they lack precision. Formal specs use some formalism to exactly define (often in some mathematics-inspired notation such as Z) the behavior of a program. Very useful if you have it, but labor intensive to produce, not too many people can read or write these comfortably, and keeping up with changing requirements is hard.
I think the selling point of pseudo-formal notation, like UML, was that it would be a "best of both worlds", where you get most of the benefit of formal specification, while the workload is more similar to informal specification.
Instead, my impression is that it's the worst of both worlds. The additional work isn't quite as high as for formal specification, but you get very little benefit for the additional work: the preciseness of your specification is still much closer to informal specs than to formal specs.
I see UML as the worst of both worlds in a slightly different opposition: ad-hoc diagrams, which aren't necessarily informal (they can be formal enough with limited, improvised concepts) versus standard diagrams, which offer no guarantee of being formal rather than vague.
The vocabulary of UML offers a useful common ground (for example, distinguishing metamodels and class diagrams from object diagrams), but fancy UML features beyond the most basic diagrams would be not only time-consuming but off topic on a whiteboard, and too cumbersome and fundamentally informal for their intended uses of detailed design and model-driven code generation, with standardization providing strictly negative value.
I think it was Kent Beck that proposed the tongue-in-cheek Galactic Markup Language, GML as his preferred alternative. It has very clear semantics: a box is a box and an arrow is an arrow.
Personally I always found that the less formalistic diagrams communicate much better since you can focus on providing the essential skeleton for your ideas rather than drowning in details that are only relevant in some contexts.
Nevertheless it would be useful if everyone knew which "arrows" mean subtyping vs. reference vs. ownership vs. instantiation, and which boxes mean action vs. object/class, etc. If you only have "arrow" and "box", you have to explain what you mean by them in the specific instance every time.
Also, UML does have some nice graphical notation like ——(o—— to denote interface and implementation (sockets and plugs).
> explain what you mean by them in the specific instance every time.
this is a feature, not a bug.
The diagram isn't a substitute for the conversation. It's an aid for the conversation (and a way of remembering what was said afterwards).
The mistake was always trying to come up with a diagramming methodology that could communicate the entire design without the need for people to talk to each other.
I’d add generating diagrams from the real code, database models, etc. as an alternative, too. General high-level diagrams don’t need the level of detail which UML requires but it’s inevitably not enough detail or accurate enough to understand the system using just the UML diagrams, so you end up with a bunch of expensive time wasted creating diagrams which don’t satisfy either audience.
A problem of UML is, even worse in UML 2, that it was developed for UML tooling vendors (IBM rhapsody, Enterprise Architect, etc.). It is as if we had one compiler vendor design and promote a Universal Programming Language, declare it as an industry standard that supersedes all alternatives and has in their interest to lock-in all programmers.
UML is just all around horrible. I can't think of a single situation where it provides any benefit. It is a huge pain in the ass to the developer, and it just inspires false confidence in managers
