UML was ultimately a flop. Back in the nineties and early 2000s people believed in things like model driven architectures and such things. You would go and develop diagrams primarily and then generate your software. Naive, I know (seen some excruciatingly misguided applications of MDA back in the day). Then agile happened, became the norm and stuff became iterative by default. People started focusing on shipping working software regularly rather than diagrams of software that don't survive the first round of refactoring (i.e. the next sprint) or any form of scrutiny by an actual developer. That's just not a thing in a rapidly evolving software project.
What's the point of having complex artifacts around that lack the ability to co-evolve with your software? There is none. End of story. Basically UML got demoted to something you scribble on a whiteboard or put in some documentation that never gets updated or appreciated. At best you get some generated UML straight from the source code for staring at if that makes you happy. It's an aspirational thing at best in most software projects and necessary but pointless bureaucracy in some places.
So, is UML relevant? Probably still a little bit for some. If you are going to draw any diagrams on a whiteboard, they might at least be as little UML-ish; why reinvent a new way of drawing the same stuff. At least being able to read/glance over the damn things is mildly useful, occassionally. Although, I must say it's been a while since I looked at a UML diagram and found them insightful/enlightening. That just doesn't happen to me a lot. I don't encounter them that often to begin with and when I do they tend to be either extremely high level or just documenting the bleedingly obvious either way.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
UML was ultimately a flop. Back in the nineties and early 2000s people believed in things like model driven architectures and such things. You would go and develop diagrams primarily and then generate your software. Naive, I know (seen some excruciatingly misguided applications of MDA back in the day). Then agile happened, became the norm and stuff became iterative by default. People started focusing on shipping working software regularly rather than diagrams of software that don't survive the first round of refactoring (i.e. the next sprint) or any form of scrutiny by an actual developer. That's just not a thing in a rapidly evolving software project.
What's the point of having complex artifacts around that lack the ability to co-evolve with your software? There is none. End of story. Basically UML got demoted to something you scribble on a whiteboard or put in some documentation that never gets updated or appreciated. At best you get some generated UML straight from the source code for staring at if that makes you happy. It's an aspirational thing at best in most software projects and necessary but pointless bureaucracy in some places.
So, is UML relevant? Probably still a little bit for some. If you are going to draw any diagrams on a whiteboard, they might at least be as little UML-ish; why reinvent a new way of drawing the same stuff. At least being able to read/glance over the damn things is mildly useful, occassionally. Although, I must say it's been a while since I looked at a UML diagram and found them insightful/enlightening. That just doesn't happen to me a lot. I don't encounter them that often to begin with and when I do they tend to be either extremely high level or just documenting the bleedingly obvious either way.