Every software engineering team in my 20+ years career actually used 2-5 types of UML diagrams: classes, sequences, deployment, activity, state. I think it mostly depends on maturity of the team and engineering culture, whether UML is used or not. There’s certainly some value in it.

>I think it mostly depends on maturity of the team

yep. kids out of college feel most inclined to use it.

With the odd caveat that you probably use sketches of these diagrams? As soon as you are trying to cram in all of the extra details stuff like class diagrams can do, you are probably wasting time.

I do not understand your question. If I do not deviate from convention but omit unimportant details, is it a sketch for you?

If you have a project document template from PMBoK, do you feel obliged to fill all the sections or you document only information relevant to your project? With UML it’s the same: it offers a lot, but you do not have to use everything to produce a conforming diagram.

It it a sketch if you don't include every detail that UML was specifically designed to convey? Yeah? Noting that a sketch is not a derogatory phrase here.

Note that, for many of these diagrams, they existed before UML. It was an attempt to formalize them. In classes, they are often used as code generation tools in an attempt to keep a 1:1 between document and code. Laudable, but I have yet to see that work out well.

To your point, I think, the same ultimately goes for document templates. Way too many are used prescriptively as a way to make a successful project. Much to the chagrin of the document writer when the project fails. Often miserably. To the point that I'm convinced most accurate project documents are after the fact. Certainly not waterfall to the project that they are describing.

> I think it mostly depends on maturity of the team and engineering culture, whether UML is used or not.

I suspect that's true: teams with a very immature engineering culture probably do use a lot more UML. It's a good way to feel like you're doing something useful instead of actually doing the hard part. Mature teams write code.

> Mature teams write code.

Sounds very Dunning-Krugerish “smart people like me do X and not smart people do Y”

Coding and documenting aren’t exclusive. Modeling is part of documenting. UML is a type of modeling.

I would think effective teams will want to build good software. And to build good software they’ll want to capture requirements, communicate with other teams, and test their software. Design helps with this and is part of coding.

At the end of a successful day, I should have some updated models, some code, and some running software. If someone wants to see what I did, they’d likely read through different parts.

Just like trying to figure out a stage by just reading models sucks, so does trying to figure it out by just running the software.

UML is not documentation, it's code for people who can't read code. UML diagrams offer no additional information to someone who already can read code (and write readable code). They are training wheels. Mature bike riders don't use training wheels. Mature teams don't write UML -- they write code instead.

Other forms of documentation have their own tradeoffs, but I was not discussing those. You're the one who automatically equated UML with all possible documentation.

> to build good software they’ll want to capture requirements, communicate with other teams, and test their software

UML is awful at all of this.

> At the end of a successful day, I should have ...

> “smart people like me do X and not smart people do Y”

You don't see the irony here?

Mature teams document their code

Part of engineering culture in general, not just software engineering, is ability to share knowledge though documentation and best practices. If you share the source code, you communicate your solution on a very low level. It is often necessary to zoom out to see the big picture and there visualization helps. You can create ad-hoc diagrams, but their expressive power is low: without a convention it’s basically just space, text, arrows and generic shapes. To increase the expressive power you need a visual language in which different shapes and lines have some semantics. And here comes UML and other diagram languages. If you are not using them, it is likely that you are not communicating efficiently. Can a mature team fail at communication? I leave the answer to you.

UML didn't help though because it is never kept up to date with what the code really is

How was it supposed to keep up? The most popular programming languages did not introduce concepts that are too hard to reflect with UML. Or do you mean the problem of maintaining documentation?

Maintaining documentation. UML cannot go even one developer-week without being updated, but the developer will often not do that. By the time your UML is a month out of date it is useless at best, and misleading at worst.

This has nothing to do with UML. Ad-hoc diagrams or plain text descriptions become outdated at the same speed, which depends only on the level of detail that you put in documentation and not on the format if it. If you cannot keep up with the changes in the code, you are choosing the wrong level of detail, that’s it.

Ad hoc diagrams are much more likely to be tossed in the trash can after a week. If you keep them longer than the same problems apply. If you only keep them for a week than ad hoc is good enough as everyone still remembers what the symbols mean from when you created it, and the next time it won't matter that the symbols mean something different

I agree with everything you said until you got to UML diagrams. The problem with UML diagrams is that they communicate exactly the same thing that the code should be communicating. Class diagrams are not higher-level than the code they describe. Instead, communicate high-level intent and interactions.

I don't think I have ever seen anybody actually getting value from a class diagram. I have seen many people creating them, but they are always useless.

I also don't think the UML variant of state machines and workflow are any popular. But well, there is probably somewhere where people use them. Also, those lists usually ignore entity-relationship diagrams, where UML just adopted the popular format (without even minor changes, like for workflows), and thus everybody uses the UML one.

But yes, people don't remember about deployment diagrams. Those are used a lot.

Class diagrams are a good way to detect circular dependencies.

If your class diagram is comprehensive enough to get circular dependencies, then I'm completely sure¹ nobody will use them for anything.

Computers are much better at this kind of checks anyway, and they don't need diagrams.

1 - Instead of "well, maybe it's possible despite I never seeing it"

> I have seen many people creating them, but they are always useless.

Not every artifact is worth keeping, instead the value can come from the process of creation as a way to structure your thoughts or to explain or brainstorm possible solution. The value of class diagrams for those people is in the moment and it’s ok to throw them away later if they become useless.

Why the university teaches outdated useless stuff? My guesses:

- For the university, it fills out offerings and takes up credit hours, keeps the tuition dollars flowing

- For the teacher, it's something they already know how to teach, so it doesn't require nearly as much effort to teach as something more useful but maybe less familiar

- Universities are trusted with the decisions of what to teach and don't face much short-term accountability, so there's no real downside to teaching a useless course for another year

- They probably don't know it's useless. (They also don't care to find out because of the aforementioned points)

My graduate program did not teach UML, but I did learn it during my undergrad program. It was a relatively small part of the major software engineering course. It introduced the idea of formally specifying software, and it forced me to reestablish, visualize, and otherwise integrate what I was simultaneously learning about things like interfaces and inheritance. It was presented as an educational tool and not at all that we would be using it in industry. Far from useless or out of date in an educational context.

I'd offer another, possible reason:

- University professors who remain exclusively in academia missed the rising tide and teach what they know

Isn't UML about conceptual thinking first, before you loose yourself in editing?

That was my take on it. How do you get students to practice the process of thinking conceptually first, then evaluate how thorough the planning is, without some tool like UML? Its one thing to lecture your students on the necessity of planning ahead. Its quite another to evaluate whether or not they know how to plan ahead.

Granted, UML is not used hardly anywhere, but I must've learned 30 different specific software tools in college that I never used outside of college. However, I've used something like each one of them. I took a technical drawing class in high school and I still use some of the techniques I learned in that, even though absolutely no one uses t-squares, triangles, and actual paper in modern technical drawing today.

There's a fair argument re: how much planning and conceptualizing should be done ahead of starting the Agile process, and also a fair argument re: what that planning should look like (crude flowchart? UML-compliant class diagram?). But in rejecting the UML tool, are we rejecting also the idea of advanced planning too? Like, how completely do you need to reject advance planning that it takes the Agile loop to reveal that the customer actually needs software that uses an observer pattern?

There's a bureaucratic reason too. Changing curricula is not fast and can take years (depending on the institution of course).

My department profs actually got in a bit of trouble with the university because they took the course that they should use for undergrad/graduate mentoring (something like a "special studies in XXX" placeholder, usually for independent or small group study that was special enough for course credit) and used it to create their own courses outside the review of approving a new course with a distinct number and credit count.

The reason they did it in the first place was because if they wanted to change the curricula for the existing courses, remove course numbers, or create new ones, the bureaucracy would take 4-8 semesters to get approval and complete. By which time some of the material was obsolete. One of the profs got fired and the rest quit, eventually.

It exists, you will see it, and when that happens you will be expected to understand what is there.

So it is well worth 1 hour or 2 to look at it.

"Useless" is a strong word. Definitely a bit less useful than intended though.

Before UML, it's hard to capture the state of corporate software development that allowed the insanity to take part. I mean, UML was the marriage of two different approaches to drawing object models that were locked in a battle: OMT and Booch method. There weren't tons of open forums for discussion and debate like the internet has now, there were conferences and such and these guys were basically trying to create formal methods for objects in a vacuum.

It was kind of existential stuff for a lot of the smaller players in the industry, everyone saw value in this newer approach to building software. "Reusable components" seemed huge. Tooling was expensive, training was expensive. Microsoft was moving as a scary rate, connect your cart to the wrong horse and it could cost you the company... On some of the usenet forums, about the most open discussion there was at the time, I read debates about the virtue of C++ style multiple inheritance vs single inheritance and there were product matrices for programming tools that had check boxes for crap like that. C++ and CLOS both supported multiple inheritance so to the casual observer they were "better." Now I've never seen serious industrial software written in CLOS or anyone even considering it but it "had the features." It was just a different and crazy time, kind of amazing how open source/free/libre has altered things, the entire culture of building software is different and probably more healthy.

Anyone want to shit on design patterns next?

I’m on the advisory board of my school’s comp sci department. Each of us advisors has our own experience and perspectives on what useful things the students should learn. Sometimes I’m arguing that no, they probably don’t need to learn RPG, just because that’s what one of my colleagues sees a lot in their branch of industry. In turn, they argue that some of my recommendations are more useful at SF tech startups than in long-term positions in the companies local to the school.

Without those various perspectives, you end up with students learning all kinds of goofy things just because no one said, nah, they’re probably not going to need that.

Activity diagrams do a decent job too. But yes, sequence and activity diagrams are all I have used.

Sequence diagrams aside (they are useful!), I also felt far too much time was wasted on UML in my university course. The only small argument I can see in favor is perhaps to encourage some thinking and discussion around software design among students in an educational context, even if I've never once seen it used in industry. I can't say I'd miss it's removal all that much either though.

> I see them used all the time in FAANG.

Does that mean something? Besides you saying you worked in them? It’s a question ; I don’t know.

It is shorthand for saying that it is used by engineers working on high-profile, high-impact, software that ships to hundreds of millions of people. Some people might argue that these teams work on some of the most important software in the world. So if the people who work on this important software do a thing, like use sequence diagrams, that is a decently good signal that the thing is useful.

Also used a lot in automotive software development processes for example. Basically, the more safety critical a system is the more formal diagramming / modelling there will be part of the design and development process. It’s important to be able to reason about complexities of such systems across a team / teams.

Was it easier the second time around? :)

It would be useful if everyone would at least be vaguely familiar with basic UML notation, i.e. action vs. object, multiplicity, connectors (association vs. composition vs. dependency vs. specialization, interface/implementation), class vs. instance, fork/join, etc. Otherwise you have to clarify over and over what means what in a diagram.

One powerful aspect of UML is that you can combine different diagram types. For example, you can use activity-diagram elements in parts of a sequence diagram.

For pragmatic use, “UML Distilled” [0] by Martin Fowler is a good introduction and reference.

[0] https://martinfowler.com/books/uml.html

>That time was mostly wasted as I've never used any of it and never met anyone who has used it.

So here's the conflict: if we agree that planning is good, communication is good, and that it is faster / cheaper to design before we build rather than rushing in to build something, then is it not a good idea to have something like UML in our tool kit? Perhaps UML was too complicated or overbearing, but I've always felt like a universal tool to describe aspects of the software we are building is fundamentally a good concept. Further, it feels like the right idea to document / designing up front in a way that increases buy-in and communicates what we are doing.

So if not UML, then what?

UML doesn't give me anything over random boxes on a whiteboard that are non standard, so long as the others understand them.

I have an undergrad friend. Learning this last semester. It's still taught, and it's still not used.

It's certainly given too much importance in the curriculum, but the idea of having a common language (with standard semantics) for sharing design decisions is valuable.

I'd argue the issue is that because UML is not seen as valuable, everyone improvises their own dialect when drawing stuff, and so since nobody trusts people following correct diagram semantics (e.g., meaning of different arrow shapes), nobody trusts the resulting diagrams either, further reinforcing the notion that it's useless.

Pretty sad assessment if it truly was useless as you say. I've found structured approaches to solution planning and design (UML, and others) to be very useful in most projects.