Sequence diagrams, the only good thing UML brought to software development

Correct uml didn't have anything to say about relational databases.

I use two types of diagrams:

Erds

and

Random blocks and arrows and icons that mean whatever I want them to mean for that particular diagram, based on whatever concept I want to communicate at that point. Maybe it's network architecture, maybe it's dataflows, maybe it's software components. Each diagram comes with some text explaining what it represents.

UML would be fine if it was not treated as a design tool, but as an inspection and visualisation tool of already (partially) built systems.

The way it is today is that when somebody insists on designing in UML the design gets created then implementation is at best only attempted, before the whole thing gets scrapped and the actual working system is built because most systems are only discovered as they are being built.

> Before UML, there were many methodologies.

UML really wasn't a methodology. It was a "visual modeling language" telling you how you should draw a picture of a code construct.

It didn't give much (if any?) advise on which development tasks you should do in which order. It was just a TOOL that could be used as part of your SW development activities.

I'm not sure how people used it. Did they first draw the picture and then code, or vice versa? Or maybe drawing the pictures was optional? A "Software Development Method" should answer such questions, among others.

A note about words: "Methodology" means something like "study of methods". A more proper word for individual documented or prescribed approaches to how to develop software would be simply "method". A "method" tells you how to do something.

In some ways, software development practices have degraded since that era. It largely has to do with the need for speed which comes at the expense of careful consideration, quality, integrity and the formal standards that support it.

In fact, I believe it pretty much killed the profession of software architect. Many teams had it as a dedicated role, and this indeed would be a person documenting/designing systems using UML or otherwise. And they'd know the classics, like memorizing all design patterns. Finally, they'd use formalized architectural decision making methodologies to justify tech choices.

Nobody seems to do anything like that anymore. Everybody is half-assing design or skipping it entirely. Solutions are reinvented and tech choices made on a whim by the loudest person whom won't see the consequences of it anyway. Because we've told ourselves that shipping garbage in short cycles is the one and only way to do things.

> Most developers IME actively reject these diagrams because they are quickly outdated, or require constant changes to keep up to date

Plans are useless, but planning is indispensable. The act of diagramming things up front is useful to get you thinking about the problem space and come up with the outline of a solution. After that, keeping the initial design documents up-to-date is optional, and often might not be necessary.