Just my opinion, but I think that folks realised it was not much use for initial design, but could work reasonably well for documentation of existing systems.

UML as a methodology seems to have disappeared, but bits of it (e.g. sequence diagrams) seem to have been absorbed by the profession at large.

We still learned UML diagrams in school in 2019, though I have to say I haven't used it anywhere in my job

I'm kind of hazy about where the boundaries between bona fide UML and PlantUML are, but PlantUML is in pretty common use in my world - more for sequence diagrams and state diagrams than class diagrams though. Of course PlantUML has competition from things like Mermaid, but they're all much of a muchness.

My very non-scientific impression is that tools like Rational were mostly used for drawing class diagrams and ... that just turned out not to be that useful because the tooling didn't exist to round-trip changes in the code back into the diagrams meaning the diagrams lost parity with the code rather quickly. It was sort of useful in the linear design/code/deliver world, but we're a lot more iterative now.

Just another data point that the "low code/no code" revolution sputtered out over a decade ago.

I still see and use a small subset of UML for more complex architecture discussions, but that's about it (i.e. service nesting, message passing, etc.).

I think folks upgraded to GML [0]

[0] https://wiki.c2.com/?GalacticModelingLanguage

UML was a scam really. They took a lot of very useful diagrams and created a absolute behemoth of unproven system to develop software and sold it.

The diagrams are very nice and useful. But the UML as a process, if taken literally, it a total disaster.

UML never matched reality and this isn’t really an engineering discipline even if we pretend it is.

You can really break UML by specifying a system then changing it a number of times. That process will hurt you. Badly.

My theory is that Agile killed it. UML requires a lot of planning up front, and in my unfortunate experience, any sort of planning is completely antithetical to Agile.

I occasionally use a “UML Lite,”[0] to illustrate stuff, but I seldom work at the scale that I would consider it necessary. I generally keep my designs in my head. Makes for much faster, and higher-quality work.

[0] https://littlegreenviper.com/the-curious-case-of-the-protoco...

IIRC it got a bit out of fashion towards the end of the 2000s along with the OOP fanatism it was closely related to.

I think its abandonment is related to the adoption of agile methodologies. UML was used to describe systems from day one. Agile methodologies came in, claiming that we don’t need it.

It's still being taught in schools AFAIK.

Had an intern a year ago whose school forced them to go the whole nine yards with UML. Our company gave them a project to build, and their school made them draw use-case diagrams, class diagrams, sequence diagrams, and activity diagrams, before the student was allowed to write any code.

This was a waste of everyone's time, and we gave the school some choice feedback which I'm sure they'll ignore.

Sequence diagrams are still used quite a lot, and for good reason, they're incredibly useful. I see simple class diagrams quite frequently as well, but without the poorly designed arrow nonsense (shaded? open? closed? argh!).

In payments and most other industries with a lot of connections to 3rd parties and complicated transactional flows, UML diagrams (especially sequence diagrams) are used a lot, albeit mostly as a conceptual tool rather than some formal description (see for example the Stripe docs). I also see UML state chart-like approaches being used more formally in frontend (e.g. XState).

Underneath the good ideas of UML was the idea of model driven development - that you could generate code from the models.

Good diagrams are an art form though, just like other forms of good documentation. There is a big difference between a diagram being a normative source of truth, and being a good tool.

Take this diagram as an example: https://takaakit.github.io/uml-diagram-for-ddd-example-in-ev...

* Nearly the top half is taken up by relations which aren't especially helpful, and would be better expressed on the entities themselves.

* The "Location" type looks like the primary type in the system based on nearly half the types in the system connecting with it, creating a nest of graph edges. However, this is likely a simple and immutable record type. If the entities in this diagram had attributes (e.g. like a class diagram), you could refer to it by name, and greatly simplify the cognitive load in understanding this picture.

This is the sort of diagram that gets generated from code, and is at the level of specificity needed to generate code from a diagram. It also isn't very useful for using the model to convey the system to a person - a developer might be more comfortable reading the code rather than looking at a picture generated from it.

IMHO, that split focus in UML between people and tooling greatly reduced the overall usefulness and understanding of the system. It gave UML a bad reputation. Training on MDD tools prevailed over providing a baseline of common nomenclature to enable "team cave drawing on a whiteboard", which has no commercial tooling or market other than the whiteboard and markers.

The areas where visual languages have a bit more prevalence are on the business modeling side, including things like network architecture diagrams.

It is a bit of a shame - going through a set of use cases while iteratively improving the architecture by improving a set of class, sequence and ECB diagrams is something I always found to be crazy efficient vs diving immediately down to prototype code.

> try to find an error in the diagrams.

Easy peasy, it's the 3rd blue line above the purple line /s

https://github.com/takaakit/uml-diagram-for-ddd-example-in-e...

I can't believe someone took time to generate such a thing, as if it is useful to anyone

One of my more painful design mistakes happened in this sort of way when designing a system for recording inspections. I interviewed multiple inspectors and came up with a representation that was a little bit more elaborate than I would have hoped, but it at least captured all information I believed.

Then the company progressed and eventually we got to market fit and for two years the team and I were dealing with this increasingly burdensome complexity that we were not reaping any rewards of. Then one day we had enough and a colleague redesigned the system to ditch the extra complexity resulting in a much more elegant design that was easier to reason about.

That bliss continued for less than a year, until some customers asked for a particular report that we needed to generate based on a structure of the information that was now no longer present. We had to redesign it again, migrating was super painful and involved a temporary workaround that basically involved an extra branch on literally every piece of code that touched the inspection system.

In retrospect, I still don't know how I could have convinced the team that the complexity was something we needed when no customer required it for 3 years. Especially when the colleagues who took over that system from me had gained much more experience and expertise in the domain than I had since I had designed the original.

It would probably have been better if I had recorded the requirement that prompted the complexity, but had not actually implemented it as no customer had actual need for it at the time. Then we would not have had to deal with the complexity the first three years, and then evolved the product when the need arose.

They're an awful substitute for code. About the best use for them is to give people an overview of the architecture of an existing system.

Even them theyre not great coz they tend to go out of date quite quickly and theyre quite expensive to build.

As a means of software design theyre BDUF crack - theyre an incitement to bad decisions in advance of writing software that would always be much better if done retrospectively via refactoring.

How about we ditch the AI slop

OO yes, but not Java particularly. I was using Rational tools with C++ projects well before Java was getting any visibility.

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.

The bottom layer of C4 is still basically UML, although everyone usually skips that.

I love IcePanel and would recommend everyone try it. But like all these things, it requires an almost superhuman level of commitment to get value out of it. It has built in mechanisms to keep you honest and up to date and I have found it useful both the strategic and tactical level when used right. But ultimately it’s difficult to build an engineering culture around long-term, living diagrams. The moment everything gets out of sync it might as well just be a photo of a whiteboard. I strongly suspect this sort of platform plus AI will be a great combination (I think at least one HNer is working on exactly that and I assume IcePanel too).

Is there an equivalent of The Mom Test for talking to domain experts?