I also find sequence diagrams to be the most useful, but disagree that the rest of UML is useless. Class, component, package, activity and state machine diagrams are all useful ways to model the structure and behavior of a system visually.
The only reason the other diagram types fell out of favor is because of the development methodology change starting in the early 2000s. The industry started rejecting Waterfall, early design and system architects, in favor of Agile, just-in-time design and empowering developers. So we saw no need for these visual design tools to model the entire system, since we ended up changing the design during the lifetime of the project anyway. The drawback of this, of course, is that with the Agile approach these diagrams never end up being made, so developers are left to assemble their own mental model of the system, which hurts the overall comprehension. Most developers IME actively reject these diagrams because they are quickly outdated, or require constant changes to keep up to date, which is true, but this is not unlike documentation, comments, and a myriad other things that needs to be synced with the code.
Yet sequence diagrams are useful in a wide variety of use cases, and let's face it, they're the easiest ones to comprehend, and are even understandable by a non-technical audience. In contrast to the other UML diagram types that have strange notations and the information is more densely packed.
I've taken a throwaway approach to diagramming, where I'll produce them more or less on demand for a meeting or presentation, but not think of them as an enduring artifact. PlantUML is my friend here because I can knock out ugly but gets-the-point-across diagrams in 30 minutes before a meeting and check them into source control, so I can then take the bones of older diagrams and rework them for a fresh meeting.
I used to whiteboard for this, but that hasn't carried over well in the remote world. What I miss about whiteboarding though is that you can tell a story as you draw, so whoever's viewing can watch something unfold from a blank slate while I'm walking them through the history of whatever system we're describing. That said, I can make a PlantUML diagram much more correct than a whiteboard.
All that said I too would love for more of that to be automated increasingly through AI. And I suppose it should make sense conceptually, because for me the value of a crafted diagram over an automated one is that no one really wants to look at the insane ERD of an OLTP database or a production object model. They want the digestible high level vision of the important bits, or the bits that are relevant to the conversation taking place. So it's a summarization problem. How to get the right data to produce a correct summary is interesting--I'm sure if I look there's a dozen papers to read on a similar subject :).
> Maybe in the not-too-distant future we will have AI grokking large code bases and cranking out accurate, useful, UML diagrams out of it.
> All those diagrams, when they are complete, correct and up-to-date, do convey what they are supposed to convey.
I spent a bit of time prototyping this recently. It's definitely possible. Rational Rose also had the capability to generate diagrams from code though. I don't remember how good it was at the task though. Was Rational Rose just a very bad implementation?
I find the hate in this chat strange because diagrams are incredibly useful when working through complex problems* and then conveying that information to other engineers. My experience over 20+ years is that a huge portion of engineers can't grok complex problems from code alone.
*Most of my projects are optimizing billion+ row databases, micro-service architectures, and various other scaling challenges.
True, though nowadays I use PlantUML (https://plantuml.com/) which is a DSL using which we can create all kinds of UML diagrams. If any changes are to be made I just need to make the incremental changes using the DSL and regenerate the images. It has been very helpful.
People who say "UML is useless" basically say "diagrams are useless". Which obviously isn't true. The alternative to UML is everyone inventing their own "diagram language" when they want to visualize something.
Moreover, I think comparing different UML diagrams can also be enlightening for university students. E.g. state machine digrams look quite similar to activity diagrams, but the former emphasize states and the latter actions. And class diagrams let you learn the connection between class structures of OOP languages and database structures.
UML lets you visually learn the abstract higher level concepts without having to rely on irrelevant specifics of practical implementations, or just on dry theoretical text.
The nice thing about visual stuff is that it is self-explanatory. Instead of needing to read a book about UML first, maybe just use some prose in addition to your diagrams, and you don't need UML at all then. That's also more flexibel.
The superior alternative is drawing a diagram on a piece of paper to exercise the mind and show to collaborators, and never setting foot anywhere close to the UML tarpit.
There are other types of diagrams beyond what UML formalizes. For example, Data Flow diagrams can be very helpful, but they don't exist in UML (Component, Composite Structure, and Activity diagrams all have similarities with Data Flow diagrams, but none are really a great fit).
> 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.
During the prototyping phase diagrams do help, but they're usually sketches written on paper or whiteboard. You don't want to waste time with tools and strict specifications to design perfect diagrams, mostly because the design will change frequently, and you don't want your tools getting in the way.
Later on, once the design has settled down and maybe once development has started, those initial diagrams are mostly worthless, but you _do_ want neat and professionally done design documents that describe the system. This allows you to share them with coworkers, and quickly onboard other developers to the project. Hopefully by then the design won't change frequently, which would make updating these a chore.
We also moved to framework heavy development where you write classes that plug into frameworks. So a POJO here and a POJO there… (everywhere a POJO) that are managed by a framework and exist only to extend the framework are marginally useful. A UML class diagram for a Spring Batch transformer that’s cobbled together from an existing CSV reader component, just isn’t that interesting or necessary.
> The only reason the other diagram types fell out of favor is because of the development methodology change starting in the early 2000s. The industry started rejecting Waterfall, early design and system architects, in favor of Agile, just-in-time design and empowering developers.
I dunno, whenever I heard people say they're doing Agile all I see is them doing Waterfall without documentation.
> Class, component, package, activity and state machine diagrams are all useful ways to model the structure and behavior of a system visually
They're not bad, but the C4 model is a much better approach to high level modelling (while you can still use class diagrams on the lowest level). https://c4model.com/
Class diagrams feel pointless to me, this information works better as code, and how do you draw a class diagram with more than 10 classes and keep it readable?
If you use class diagrams to show the "truth" you are in painland in my experience.
However I sometimes find them useful to extract key parts of the system and showing their interaction. Cutting away many attributes, many helper classes, many other things.
That can lead to pictures which are quick to grasp and then allow further digging based on code.
Maybe before you actually start writing code its nice to create some domain diagrams which you can convert to class diagrams. Saves a ton of time. And you have good discussions about the general high level workings of an architecture. Can be done on a whiteboard. Make some pics and start coding.
I think class diagrams are a good way to visually display classes and hierarchy. If I have a package or module that has 10 classes and I want to show inheritance, properties, and methods I think it’s easier to show the class diagram then hand someone 10+ source files.
Also, class diagrams are more useful when you can’t give out source.
That being said, I think you can autogenerate class diagrams from code so it’s not like you should spend a lot of time making them.
UML was (and still is) really useful when embarking on a greenfield design. Most people I've worked with know some basic UML notation, so when it comes to whiteboarding and refining the design, it makes sense to go with that.
In terms of artifacts for future maintainers? Maybe not as helpful. As previous posters have mentioned, the diagrams go stale very quickly if the engineering department isn't disciplined about keeping documentation up to date. But this is true for any documentation.
Some diagrams (class and activity, in particular) are less valuable as time passes. I can get the idea of the class structure by just looking at the code itself. The class diagram just ends up being a stale representation of the code.
It is unfortunate that UML has developed a reputation as being overly complex. Now I see more ad-hoc diagrams being created, with whatever notation/symbols make sense to author, rather than using a common diagram system that can be read by many.
> The industry started rejecting Waterfall, early design and system architects, in favor of Agile, just-in-time design and empowering developers. So we saw no need for these visual design tools to model the entire system, since we ended up changing the design during the lifetime of the project anyway.
It wasn't also visual design tools that Agile killed. Agile killed design documentation altogether.
With Agile, today's problems are addressed on tomorrow's sprint, and changes in software architecture take place only in the code. Any effort to document the system architecture in any remotely rigorous way is quickly deprecated, and teams simply don't waste time maintaining something that might already be deprecated once they finish editing the document.
Does anyone else find the agile way of doing things just ends up with lots of increments and no big picture of how the system should be or where it should be going? There also seems to be a with with waterfall that it's a one way process and you can't do iterations.
Maybe UML can find a new life with ChatGPT. Maybe it can fulfill the promise of generating code out of diagrams. UML seems like a fine way to organize prompts.
Spot on, I agree that sequence diagrams are super useful, I see them used all the time in FAANG.
I do really wonder why UML is still taught in universities, as the article states, it's pretty useless. I took a masters Software Engineering course at Georgia Tech two years ago and a big part of the class was learning UML. That time was mostly wasted as I've never used any of it and never met anyone who has used it.
It wasn't my first time learning it either, we also had a section on it in my undergrad software engineering course. So I learned the same useless stuff twice.
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.
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.
"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.
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.
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 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.
> 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.
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.
>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.
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, swimlanes, 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.
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.
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.
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.
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.
Used consistently it really helps a lingua franca across teams. Which was the UML aim all along, but it got caught in into "Enterprise Bloat" (like SOAP or XML)
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.
Yeah, hard disagree on all that. As someone who lived through that era professionally, and who has had an "architect" title in the past, I was actually resistant to ever stepping into that role, because I had so many bad experience with the Formal Architecture Methodology crew, who would produce the most absurd and out-of-touch designs. There's a reason that "architecture astronaut" is a term from that era.
Lots of people make bad designs today, sure, but it's not for a lack of formal methodologies, because average design quality was way worse back in the design patterns 'n' UML days.
Seconded. I once went to an IBM seminar with Grady Booch and seldom have I heard such an inane string of platitudes. Architecture Astronauts are the worst, and if there is one thing Agile can legitimately claim for, it's getting us rid of that plague.
I don't think it was software architecture, UML or design patterns that was bad. I think the 'Open-Closed Principle' is one of the worst ideas to ever gain popular acceptance.
For anyone who didn't live through that time, the Open-Closed Principle states that software should be open for extension, but closed for modification.
However, you could also rephrase that principle to be: 'you should always prematurely abstract your designs'.
I think if abstraction was viewed as a negative to be avoided unless necessary, software architecture would have been far better off.
To be fair, premature abstraction is a lot of fun for those that do it. It's just those that follow who aren't so keen.
I’d argue software architecture has never been more healthy.
DDD Europe by all accounts was a resounding success. We’ve replaced older architecture activities like data modeling first with event modeling and Domain-Driven Design.
We’ve learned to embrace monoliths when appropriate and reduce complexity with bounded contexts.
We have phenomenal testing capabilities that didn’t exist 20 years ago.
We have a myriad of data storage tools.
We understand front-end engineering from an information architecture perspective.
We can design detailed architectures in tools like LucidChart very quickly with detailed solution details.
I’ve been at this for 40 years and I’ve never felt better about being a software architect.
Could we bring back the UI people from that era though? Trying to standardize good software is insane but having a consistent UI with standard elements for all programs that's usable with both mouse and keyboard was kind of nice.
> And they'd know the classics, like memorizing all design patterns.
That sentence is bringing back ptsd-like flashbacks.
I remember distinctly how much everyone thought that approach you describe was broken when it was the trendy thing.
I'm not sure how universal it ever was, but it was at one point a trendy thing that everyone thought they should be doing... and that so many people subject to found disastrous. [The phrase "architecture astronaut" was a common epithet, and not a friendly one]
That above paragraph [without the brackets], ironically, could certainly be said of "agile" more recently too. I don't know how universal it ever was, but it was at one point a trendy thing that everyone thought they should be doing... and that so many people subject to found disastrous.
But yeah, I'm pretty convinced going back to appointing some almighty deity architecture astronaut who isn't responsible for or involved in any implementation (let alone operations!), who hands down plans from on high after "memorizing all design patterns" and drafting some diagrams, never sullied by "contact with the enemy"... no thank you, but thank you.
----
Instead of just complaining about that though, what I'll say in addition is -- I think the real problem is that engineers aren't given the time to carefully consider top-level designs. it's a basic business/resource issue -- until engineers have more breathing room to talk to each other and research and consider and come to decisions in an unhurried way, the top-level design stuff will remain chaotic. It's not an issue of appointing an ivory tower "architect", or something solved by it.
Although sure, there should be senior and even "staff" or "principal" people with more authority/responsibility for higher-level designs.
Everyone should be responsible for design at the level they are working. Everyone needs enough time to feel like they are doing it well, instead of running on a sweatshop code production treadmill.
To be fair to the design patterns people, a lot of them got baked into pieces of infrastructure like web servers and frameworks, while others are part of frequently included libraries.
If I went through and inspected any Node, Rails, Django, etc app I would find many Gang of Four design patterns, but very few of them would be in the project-specific code. They got implemented well, and now programmers can build new things that would have taken too long to do before.
And that was the intent of the Gang of Four book, not to teach you patterns you should copy mindlessly, but to give examples of how to identify and extract useful patterns from the software you've already written and describe them to others. Since that is a lot more difficult than memorization, very few took up that work.
I tend to agree about the time thing, namely that people aren't given enough of it to sit down and take their time with design decisions. If you squint you can kind of see that "software architects" are a business's way of creating a "solution" to this problem, but with lackluster results.
That said, I've been at places where management did a pretty good job of making sure that there was enough time to do this kind of work with middling results. People have to enjoy the work or feel invested in a way that makes them care about "3 years from now", and sadly in a lot of places there's a lot of "whatever, it'll be fine for as long as I work here."
It seemed to me that in let's say 50% of cases, having the extra time didn't really matter. Assumptions about what was being built were proven incorrect not long after a design was laid down and work had begun, or particular engineering types would create increasingly complicated designs with their time rather than doing the hard work of distilling the problem, sometimes including $PET_TECHNOLOGY as part of their solution.
The "let's design something truly great" really has to be in a team's DNA in my experience or you wind up with a good design that isn't followed, one person who does all the work, a gold plated design, etc.
That’s because software architecture is something any senior employee should be able to do, and it’s not as important as people thought.
Like many abandoned corporate practices, I think it was abandoned for good reason. It may have made sense under different circumstances, like when you had a large army of cheap offshore devs who could not be trusted to architect a maintainable application.
If I had some ivory tower “architect” trying to interfere with my work I’d be so pissed. Anybody I’ve seen with that title, that wasn’t doing 1P cloud consulting where the title means something different, usually had no clue what they were doing and had been given the title as a soft retirement.
As much as I do think that software architecture does matter (though it should probably be somebody with a staff or principal hat, not a specific job title) I recently took a job at a place that really does like architect titles. Mine's even "lead architect".
It is pretty funny when somebody runs into me and realizes for the first time that I have the job because I build stuff and write code, not because I'm good at LucidChart. I'm planning things out beyond immediate needs, but not because I'm looking for job security--it's because I've built the thing we're doing before and would like to not make the same mistakes I've made in the past. I'm over here demanding adequate standards of code and low- to mid-level design, and the "wait he's serious?" of it is sometimes honestly pretty fun to run up against.
German speaking. You can take German IT to get an idea what would have happened to SWE if you'd have kept those bureaucratic methods from the 2000s as the backbone of all SWE endeavors: a horrible, expensive, non-working mess with barely any progress.
I think what many people, esp. from outside the SWE world, don't get: Software engineering is a deeply social kind of work. There are dozens of solutions for the given problems, you have to agree on one that works for all peers. That's the job. Optimizing it for drawing funny diagrams is not an issue if not for communication.
I'm also interested in the german software engineering culture. And also, heavy plus to this being a social problem more than a "engineers just need more time" problem. I tried to articulate this in another comment of mine but mostly beat around the bush. This is more directly what I was attempting to say.
We stopped doing that stuff because it was useless. We eliminated those practices and that profession because it was actively harmful to making good software. All those decision making methodologies consistently lead to worse technology choices than one dude actually trying to write some code with the thing for half an hour.
UML is mostly useless, but thinking ahead, even a bit, has value. I've seen stuff shipped in a sprint that was not used by any actual end users, only to be "redone" in the next sprint.
The problem is that the expection was to document the software design in excruciating details (e.g. class diagrams with all fields and methods, etc.) before any coding. To the extreme you were meant to all the coding in your head and a Word document before doing it again in your IDE.
This wastes a huge amount of time and usually the documents become obsolete as soon as you try to actually run some code.
This is the very issue the Agile manifesto identifies and proposes a solution to when it says "working software over comprehensive documentation". 'Comprehensive' is a key word as they don't mean NO documentation but effectively just what's needed to plan and help people understand the code.
I don’t think this is any more true than it ever was. If anything, the rise of open source libraries, GitHub and friends has made it easier than ever to reuse software and avoid NIH. This has lead to a different set of problems, but relative to when I was writing C in the 90s I’d say software reuse and design is far advanced from those days.
I do however agree that design is sorely missing from the current software project management zeitgeist, which means it’s done in a more ad hoc way. People are taking frameworks like Scrum far too literally, and I agree that in some cases there is little vision or overall architecture because the framework doesn’t include these things. There should be design and review activities both before and after coding, but these are largely neglected from most project management frameworks. Scrum for example doesn’t even include backlog management, which in my work is a critical activity.
While that doesn’t mean design, architecture and scope management is not done, it’s certainly less visible than it might be.
All of that said, I’m a big believer that the ultimate expression of any design is code. The design artefacts that come before code is written are scaffolding, age quickly, and are soon useless. So there’s not much need to keep them around, and they are mostly of interest as preliminary directions.
> In fact, I believe it pretty much killed the profession of software architect.
And thank goodness. I am all in favor of more consideration, more quality, more integrity. I like good architecture. But I think it's a giant mistake to create a software architect role. Every company where I saw that in practice, the average architect was a bloviator who did no actual work but was very excited to tell everybody else how to work.
At the code level, this resulted in a lot of messes. The edicts and white papers sounded good in theory to the kind of people who decided the bonuses of the architects. But frequently they were unworkable in practice, causing a lot of code that conformed to the theory but was a pain to actually deal with.
I agree with you that a lot of things are half-assed and rushed, of course. But we are never going back to a world of 18-36 month release cycles where people could stroke their chins for a quarter or two before building anything. Instead, we need to move in the direction of continually investing in quality, so that the design of systems improves over time. Something that I think is actually easier, in that waterfall design practices locked in important decisions early on, when people knew the least.
We haven't told ourselves that shipping garbage in short cycles is the only way to do things. The market has pretty much determined that companies that over invest in formal software design activities lose out competitively in the long run, and the survivors are the ones with the right balance. You're welcome to prove the market wrong.
> The market has pretty much determined that companies that over invest in formal software design activities lose out competitively in the long run
The same market that gave us AT&T, Comcast, DRMed IoT Juice presses, FTX, Enron, and so on? Not sure it’s wise to conclude that the market produces optimal solutions, or even incrementally better solutions than yesterday. Especially in domains with extremely long feedback cycles, like organizational trends.
I DO think there is some hocus pocus market zeitgeist that does something resembling gradient descent, but it’s acting over very long cycles and there’s a ton of room for cargo culting, grifting, and opportunistic grabs along the way. Heck, marketing is an entire field dedicated to affecting “rational actors” in the marketplace.
The pendulum swung, and now we bias towards action rather than design. But to be honest, the "software architect" era wasn't great either, with people in the role sometimes not qualified, spending months on an architecture behind the curtain, releasing some over-verbose spec document that doesn't match the product needs, cargo-culting the latest fad from Martin Fowler.
The problem you're describing Exists in all engineering disciplines. You don't hire firm to feasibility studies, develop a design plan, do a materials bid, sub contract clearing and construction for your mailbox installation do you? Most people hire a dude hanging out at Home Depot and pay him a flat fee.
The risk and complexity dictate how much architecture and engineering are involved and with all things, businesses will try to get by with a bare minimum. The automotive, chemical, and other industrial sectors invest a lot in software architecture and enterprise architecture because the risk is so high. But even a medium size e-commerce platform has very low risk or complexity.
while i feel as if i largely understand what you're pointing out, i kinda want to offer my own speculation as a SWE who is very guilty in thinking in terms of sequence diagrams (and also more formal UML) -- sometimes UML is so fucking bogged down with (impl) details, i am just over here going "i don't give a shit about the (impl) details, i just want to know the abstract concept(s), and logical flows, and focus on necessary system interactions" -- bc i can (and should at this stage) worry about (impl) details later.
i prefer to reason about a system and component relationships using, say, a single word as representation, instead of glaring at one or many inheritance directionals, interface details, and other "field" information, which is usually conveyed in a UML node.
i do not think the lack of formalism is a degradation -- we work with abstractions after-all, so it makes sense to further leverage that fact and express things simply, at a high-level, and straight-forwardly -- you can pack a lot into a single word.
of course as the nature of any tool, there is a time and a place for its application. but i don't think it is fair to call it a degradation.
I've noticed the "over-detailed" problem a lot at my company that has dedicated "software architect" roles. IMO part of the issue is that most of them do not write any code anymore, but 'architecture' alone just doesn't have a full-time job's worth of stuff to do (or they're bad about finding it). The 'solution' they end up on is just treating UML like code and specifying exactly how they would have written the whole thing - which is a huge waste of time when they could have just been writing real code.
Software architects, much like real architects, often end up with absolutely beautiful elegant designs which are unfit for purpose and have leaky roofs.
And other architects make buildings/software that gets done on time because unlike babies adding people can make things go faster (it is always sub linear, but good architecture can get close to linear, while bad can go negative slope)
> 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.
Now hardware and bandwidth is so cheap now you dont have to care about design so much. Make a service, JSON in JSON out. Some kind of loose versioning but no formal schema and fix it up as it goes.
Sequence diagrams and state machines should be probably taught much better in CS courses. You generally see state machines in a theoretical course and things like sequence diagrams in an object oriented course.
What we should do is probably in your advanced data structure programming course that everyone has to take is to create a model of an elevator and diagram the behavior using a sequence diagrams. This would be achieved by using an associative array AKA a map [1] that would represent where the elevator is and what it has to do next (current state and next state based on input).
If you program this correctly it gets around using unit testing even because you have diagramed and all parts of the system are known and can just be gone through and that would be a sufficient test. An example of a library that implements this is at https://pypi.org/project/python-statemachine/
Overdesign is one of the worst things to do. Trying to make something fit perfectly into some obscure pattern with horrible class hierarchies.
Look at the linux kernel sources, it does not look "beautiful" to some architects but the actual ideas and patterns are simple, anyone can jump into it if they know C.
No, that's the era of worst, shittiest legacy software to date. The computers were just fast enough to handle layers and layers of extraction and oh boy industry loved to pile them one and UML was just another way to pile up the rot
- There's very high-level engineering occurring ('computer science'). I always assumed this would be at places with 'web-scale' problems, but I've been seeing amazing work in local (not-web-scale) product companies here in Australia.
- On the other hand, I think a lot of other development work is not much above building flat-pack furniture. I guess this is where lo/no-code solutions will thrive
The important thing is to recognise which is being done, and which practices apply each case.
In my short experience this is mostly due to OOP falling out of style, being replaced by a more hybrid approach that combines a lot of functional programming, procedural programming, and OOP - that, together with newer languages providing alternatives for inheritance (traits/concepts), and such, you rarely find yourself needing much more than visitor- and factory pattern.
I disagree. Software back then used to just fail as often, there was just less of it. Now there's lots of working software, most software sucks and lots of it fails. But the people paying well, and enabling their teams usually get good software at a reasonable price reflecting the complexity.
The project management triangle never stopped existing.
Apparently, you probably haven't started a real business or created a real successful product . This is what people believe when they are just a cog in the machine and they believe they can spend countless time designing or planning for things that are out of touch with reality
I can’t remember where I read this (Martin Fowler maybe?), but I agree that “box and line” diagrams should be enough for most design cases.
I was eager to use UML when it came out but I agree with the article, the only thing I kept was sequence diagrams. Most of the rest of it was just a complicated way to represent stuff that is best represented in code or plain documentation.
I’m also not afraid to use stuff that’s out of fashion. I use simplified ER diagrams, and even flow charts on occasion.
But the tool I use most often in design is SQL DDL…
I have also used Mermaid (using a modified Docsy theme in Hugo) and it is also great. Using Typora to edit Mermaid is also excellent.
Aggressive IDE-supported semi-automated refactoring has replaced UML. Modern languages have been designed with toolability in mind. Modern IDEs allow ruthless redesign of the architecture of code on the fly, allowing architecture to be modified to reflect actual need rather being a fairytale written before the first line of code gets written.
Teams aren't shunning design. They're just doing it incrementally, because as it turns out, trying to design a piece of software before the first line of code is written doesn't actually work.
Even in peak UML (2000 or so) there were no really practical UML diagramming tools. (Rational Rose was impractically expensive, and buggy enough that it was a race to see if it wouldn't crash before you actually finished your diagram).
Corel Draw had passable UML diagraming support. But I don't imagine it still does.
Draw the boxes and lines and make sure that people understand what they mean. Describe the system from the perspective of the reader. Just like a real architect will have different drawings/plans/elevations for their customer, the planning authorities, and the builder.
The architecture diagrams are meant to communicate the design, not comply with some over-worked standard.
UML was a clusterfuck that evolved from the trifecta of late 90s OOP (inheritance not composition), design patterns that mostly provided fill-ins for what was missing from Java as a language, the ridiculous concepts of generating code from diagrams that could be regenerated from code, which never, ever, worked, in the same way that ORMs have an impedance mismatch between OO and relational logic.
It was yet another silver bullet, the late 70s/early 80s had "structured programming", the late 80s/early 90s had CASE, the 90s had all the stupid diagramming tools where people argued about the shape of the bubbles and what arrows to put on the lines.
There was also the Capability Maturity Model, where everyone was trying to get to "Level 5" which was only useful if you were doing exactly the same software over and over again, along with the "6 Sigma" and "Black Belt" nonsense.
The 2000s had the "iterative Rational Unified Process" (an excuse to sell expensive tools from IBM), along with CORBA et al.
The last decade has suffered from the Agile-with-a-capital-A and especially "Scaled Agile" which is just an excuse for project managers to again treat programmers as fungible, while losing all of the affordances of actual project management, like GANTT, critical path, S curves, earned value etc.
Sprints are nonsense, so is "t shirt" sizing and velocity and burn down charts, and retrospectives and scrum "masters".
There are a couple of useful things:
* Domain Driven Design, using Names That Make Sense To The Customer
* Entity Relationship Diagrams, where the Entities are the same Names as the DDD
* State Diagrams for those Entities, describing the events that will cause them to change state
* Event definitions that match the State Diagram transitions, where externally generated events end up being your external API.
Bah, I've been in this industry for almost 40 years and its the same shit over and over, just with different names, and different consultants selling expensive courses.
Don't take this as an endorsement of BDUF practices and the like, they're as fraught as anything, but it's important to also recognize what modern development practices trend hard towards themselves: the trapping of oneself in a local maximum.
I have a blog post in the works about this but it's not ready to share; in short, I can't help but notice that hyper-focused, optimize-for-time-to-market, minimum-viable-product projects have a real, and frequently killer, problem once you have built your initial, hopefully-better mousetrap. Almost every company I've ever worked for has gotten that initial mousetrap done, tried to expand horizontally to actually have enough stuff-that-works-together to actually sell, and fallen on their faces because that initial super-specific development effort created not just code, but product assumptions that are prohibitive to unwind.
Most of them hit the hillside because reality is no longer playing ball with their (frequently VC-driven) needs to cut scope and ship.
Yeah, Mermaid gets it. Mermaid . . wait a second . . oh, ok, these are the same people that do Mermaid.js, they're just trying to make a living doing it.
Another useful chart type provided by Mermaid.js is the git diagram, which I use all the time when brainstorming change processes, especially for other folks who might not be git-conversant.
I find Mermaid's syntax difficult to use and understand past the simplest examples. I've also run into some strange edge cases with it, but can't remember the details right now.
Is there a way to get a git diagram out of D2? It does have nicely streamlined syntax.
One thing that worries me is that the profusion of text-based graph description languages will result in a family of software that's unparseable due to its success. We have Graphviz, GNUplot, PlantUML, BlockDiag, Mermaid, Kroki, Vega, and too many others to count - but we don't have a Pandoc.
Thinking "the only good thing" is understandable, since there's a lot of noise, but that talk discourages people from learning a lot of good stuff that's buried.
Before UML, there were many methodologies. UML was started by a unified team of some of the most noted OO methodologists.
There was a lot of good thinking, but one of the adoption problems we had before UML (as tools developers and methodologists) was that many people got a poor introduction to it, and missed the whole point.
For example, on a diagram metamodel that emphasized formalizing and visualizing the relationships among objects... some people would think it was a TPS Cover Sheet task, to laboriously draw their class inheritance hierarchy and summarize their attributes and method signatures, for purely corporate bureaucratic reasons.
You could also contrast people who needed to build complex embedded system behavior, for whom Statecharts were a very valuable tool for keeping the model manageable -- distinguished from people who were told to do it when it wasn't appropriate, and they just kinda tried to document their code control flow by misusing that same diagram notation.
Today, I can't blame people for not understanding, since most examples they'll now see are incorrect noise, and the current UML spec itself doesn't do this reputation any favors.
Half-seriously, maybe we could use a reset, in which people who neither know or care what they're doing stop being required to go through the motions of pretending to do it. Also stop trying to have people who don't actually use it teach it to students who just want a good grade in the class (for their FAANG job application), and who have little-to-no experience necessary to appreciate the real thing. Also don't make it a marketable resume keyword. Then the only people who will be doing or talking about it are people who care enough to figure out the genuine merits, with no incentive to pretend.
Then, ideally, the only time others will see it is when someone whips out a formalized diagram for something complicated, and proceeds to start explaining it by walking the audience through the diagram... Some people in the audience will get the tingles, as they're not only understanding, but they're also sensing a very powerful modeling tool that would address some problems that they and their team have in their work. (Realistically, this would start to happen, but as soon as it becomes a resume keyword or interview ritual, history would repeat, but maybe that time with a larger mitigating mass of people who understand and appreciate.)
>There was a lot of good thinking, but one of the adoption problems we had before UML (as tools developers and methodologists) was that many people got a poor introduction to it, and missed the whole point.
Not really, UML was doomed from start due to increased time to market metric. And frankly you can read the code if you are working on the already built system. Remember that software usually does not need to be correct, or even well designed to support a business case. It is one of software greatest strengths and weaknesses compared to other disciplines.
It does helps in some integration tasks, and works decently as schema definition language that's format agnostic.
I'll also concede that state diagrams are good, but well.. they are also quite simple.
Then there's readability issue - unless you worked tons with UML you WILL make mistakes when it comes to object relationship counts, and there's a lot of other non-obvious gotchas for newcomers(i used to teach reading entity relationship diagrams to non-technical people so they could understand the model they were working with, as it was a part of legal bill).
Not to mention that only proponents of UML that i've personally met, were people who were stuck in academia, and never worked on any real software product..
And even for R&D work on a harder problems it's usually easier to write a toy side project and test solutions.
Code you write in such toy project IS an entity relationship model. Tests, and example usage is a happy path of sequence.
etc.
You might enjoy looking a little deeper. For one example:
> I'll also concede that state diagrams are good, but well.. they are also quite simple.
One of the goals of state modeling is to simplify. A sufficient metamodel will include (in addition to states and transitions on events that people might see in automata theory and misc. CS education) less-simple features like concurrency, superstates, transition guards, maybe real-time constraints.
When you need a nontrivial system to actually work, in all cases, (not just toss your sprint task over the wall, and then do bug tasks later) good use of the abstractions of this "simple" diagram, and inspecting it, will tend to avert problems that even an unusually conscientious programmer might miss in just code. And it also helps communicate less-ambiguously to others who come later and need to evolve the code. Unlike formal proofs, it's pretty accessible to read.
(It can be too accessible, in that people who are accustomed to seeing hand-wavy business diagrams with ad hoc notation used inconsistently think they also get the gist of this diagram, while not realizing how much more rigorous it is. But that's not a big problem -- you just have to walk them through it, ask questions to confirm facts expressed, emphasize when something has to be precise and exhaustive, etc. The problems are more when the diagram is poor, yet the technical appearance confers an undeserved aura of respectability, and people who can't tell the difference, act on that, but that's not unique to these diagrams.)
I've seen people spend days and days trying to save a few hours of paper design time.
We often do quick paper or marker board designs, which often have some UML. You don't want to spend more than 10% of your time on this, but it can save quite a bit of time to market. If someone really wants the design saved somewhere, we just take a pic and upload it.
Is ERD part of UML? I find ERDs useful representations of databases. They can be generated automatically and are very good for quickly locating the right tables for a query. So I wanted to add a comment stating this to the parent - but then I googled to check if they really are part of UML - and it seems that they predate UML and are not really related.
I wonder if there's a parallel here with the journey that some people go on with respect to design documentation in general. In can be easy to have a mandate from on high that your process should be research -> planning -> design -> review -> implementation -> review -> ship, and that the design doc is the key deliverable between the design and implementation stages. You can even argue that this is an "agile" process, if there's a feedback loop that permits the design to be revised as further discovery emerges during implementation.
But the reality is that an awful lot of the software we build just isn't complex enough to warrant all this ceremony. It's not branchy, there's no significant error handling to talk about, no big new dependencies being added, no security implications, no long-term maintenance of an external interface— it's just grabbing widgets from pile A, frobnicating them, and dropping them on pile B. There's barely enough there to even unit test much less write a "design doc" about and agonize over in a meeting with bigwigs.
And unfortunately a lot of the projects that junior developers start out with look exactly like this. Boring, obvious code that does one thing in the exact boring, obvious way that you'd expect. So it's easy to fall out of the habit of thinking intentionally about design, until you're suddenly faced with a big thorny problem that legitimately has multiple paths forward, and what starts as a rubber-duck conversation with the person beside you eventually becomes "hmm... I think I need to write down a page or two that describes these options, gives background on why the choice matters, describes why the selection was made that was made; then maybe afterward I'll circulate that document to my colleagues for their review and thumbs-up, because maybe there's something I'm overlooking here that they could contribute to?"
Some of these methodologies and their tools have been used very successfully. By people who built complex systems that really needed to come together and work correctly.
I'm addressing the masses of us Webrogrammers, who classify all that space as "UML", and dismiss it. Not everyone is just going to be tossing (ChatGPT-assisted) sprint tasks over the wall, while calculating when to make their next job hop. Some teams will have to build complex things that work, and they can benefit from informed and judicious use of abstractions and views on the system.
Definitely, bad diagrams (as opposed to bad diagram notation) give UML a bad name. Your example of the misuse of state diagrams as a glorified flowchart is something I see very often.
Undergraduate students probably don't have the experience and design maturity to fully appreciate when and how to use most UML diagrams. I think you need to get stuck at design problems a few times before you can appreciate the need to capture ideas using the right diagram, and then you might be ready to adopt some standard so you can share your design decisions with others in a way that correctly captures and conveys just the right amount of detail.
Part of the disconnect is formal modeling methods vs informal. There is tremendous value in having a shared understanding of the architecture of system such as how components interact, the data model and any type of sequence or state modeling if needed. That can sometimes be accomplished just with ephemeral whiteboard diagrams and sometimes more complex situations require deeper analysis.
The challenge comes when trying to document the entirety of the system, and keep that up to date. The overhead is too high and complexity is such that it defeats the value of a model used to communicate shared understanding.
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.
I like the class diagram notation, although I get frustrated at the tendency to try to auto-generate it, which ends up including way more detail than is useful.
> Half-seriously, maybe we could use a reset, in which people who neither know or care what they're doing stop being required to go through the motions of pretending to do it.
UML. Use what you need, but need what you use.
Come to think of it, that probably applies to abstraction. And threads. And probably several other things.
Sounds like you never had to deliver something created with that god awful Rational Rose crapware. Who's genius idea was to use UML as a code skeleton generator? That is a perfect the recipe to guarantee your non-lead developers never gain any ownership nor intimacy with the software they are working on.
The only organizations using UML were bureaucratic heavy nightmare places to work too.
Sequence diagrams are very useful, but UML just adopted a representation that already existed decades before. For example, the original 1981 TCP specification in RFC 793 [0] has ASCII sequence diagrams (see figures 7 to 14, etc). I don't know if they predate that - less from that era is online - but I wouldn't be surprised.
Sequence and activity diagrams were already present in Jacobsons original method, which again is based on the "Ericsson Approach" (originating in 1967), long before UML; they were called interaction diagram and state transition graph.
Exactly, UML mostly borrowed from existing representations and its purpose was standardizing semantics and providing some consistency among the diagrams.
I thought UML was pretty great when it came out.
It attempted to establish a uniform manner to model
and communicate out software models / systems.
I still think it is great.
People who never learned about UML tend to reinvent
some such thing when they wish to communicate the same
structures and information.
Then you end up with 10 different people drawing approximately
the same information in 10 different forms, and all will
require some level of explanation of notation and grammar
for others to grok it.
A class diagram can contain a lot of rather valuable information.
I do agree that sequence diagrams are great, but if you rip
them out of context and throw the rest in the bin it can only
partially communicate, whereas if you had the object model to
study as well as the sequence diagrams new connections can be
quickly made.
To this day I prefer to create my object structures in a UML
diagram. Plenty of software takes it creates the code, or
takes the code and produces the diagram.
I love creating the diagram(s) when I first start working on an
existing system.
What I have seen of code generation off of sequence diagrams have
bit hit or miss. more miss. But reverse engineering sequence diagrams
can be quite revealing.
I agree completely. I tend to do 'UML light', where I don't worry about the finer details (e.g. marking fields public or private). The best solution is one where I can sketch out the outlines of a class and have some tool automatically generate UML which I can then edit.
And C4 diagrams are great for explaining software architecture, which wouldn't have been possible without UML and esp. class diagrams.
Readit News
The only reason the other diagram types fell out of favor is because of the development methodology change starting in the early 2000s. The industry started rejecting Waterfall, early design and system architects, in favor of Agile, just-in-time design and empowering developers. So we saw no need for these visual design tools to model the entire system, since we ended up changing the design during the lifetime of the project anyway. The drawback of this, of course, is that with the Agile approach these diagrams never end up being made, so developers are left to assemble their own mental model of the system, which hurts the overall comprehension. Most developers IME actively reject these diagrams because they are quickly outdated, or require constant changes to keep up to date, which is true, but this is not unlike documentation, comments, and a myriad other things that needs to be synced with the code.
Yet sequence diagrams are useful in a wide variety of use cases, and let's face it, they're the easiest ones to comprehend, and are even understandable by a non-technical audience. In contrast to the other UML diagram types that have strange notations and the information is more densely packed.
I completely agree with you.
It's a good way for other people to present information, for me to look at.
I just won't do it myself.
It's not only me; and that's why it's dead.
I won't do it because the first thing that comes to mind is how it will go out of date in a month, and have to be maintained to stay accurate.
Maybe in the not-too-distant future we will have AI grokking large code bases and cranking out accurate, useful, UML diagrams out of it.
All those diagrams, when they are complete, correct and up-to-date, do convey what they are supposed to convey.
I used to whiteboard for this, but that hasn't carried over well in the remote world. What I miss about whiteboarding though is that you can tell a story as you draw, so whoever's viewing can watch something unfold from a blank slate while I'm walking them through the history of whatever system we're describing. That said, I can make a PlantUML diagram much more correct than a whiteboard.
All that said I too would love for more of that to be automated increasingly through AI. And I suppose it should make sense conceptually, because for me the value of a crafted diagram over an automated one is that no one really wants to look at the insane ERD of an OLTP database or a production object model. They want the digestible high level vision of the important bits, or the bits that are relevant to the conversation taking place. So it's a summarization problem. How to get the right data to produce a correct summary is interesting--I'm sure if I look there's a dozen papers to read on a similar subject :).
> All those diagrams, when they are complete, correct and up-to-date, do convey what they are supposed to convey.
I spent a bit of time prototyping this recently. It's definitely possible. Rational Rose also had the capability to generate diagrams from code though. I don't remember how good it was at the task though. Was Rational Rose just a very bad implementation?
I find the hate in this chat strange because diagrams are incredibly useful when working through complex problems* and then conveying that information to other engineers. My experience over 20+ years is that a huge portion of engineers can't grok complex problems from code alone.
*Most of my projects are optimizing billion+ row databases, micro-service architectures, and various other scaling challenges.
Moreover, I think comparing different UML diagrams can also be enlightening for university students. E.g. state machine digrams look quite similar to activity diagrams, but the former emphasize states and the latter actions. And class diagrams let you learn the connection between class structures of OOP languages and database structures.
UML lets you visually learn the abstract higher level concepts without having to rely on irrelevant specifics of practical implementations, or just on dry theoretical text.
This is clearly better than UML. UML is full of shorthands that nobody remembers. That's worse than people making labelled custom diagrams.
Here's an example:
https://buck2.build/docs/concepts/concept_map/
Imagine how much worse that would be with UML arrows.
Starting with UML to describe a set of classes or - worse yet - an entire system is lunacy and a massive red flag.
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.
During the prototyping phase diagrams do help, but they're usually sketches written on paper or whiteboard. You don't want to waste time with tools and strict specifications to design perfect diagrams, mostly because the design will change frequently, and you don't want your tools getting in the way.
Later on, once the design has settled down and maybe once development has started, those initial diagrams are mostly worthless, but you _do_ want neat and professionally done design documents that describe the system. This allows you to share them with coworkers, and quickly onboard other developers to the project. Hopefully by then the design won't change frequently, which would make updating these a chore.
I dunno, whenever I heard people say they're doing Agile all I see is them doing Waterfall without documentation.
They're not bad, but the C4 model is a much better approach to high level modelling (while you can still use class diagrams on the lowest level). https://c4model.com/
However I sometimes find them useful to extract key parts of the system and showing their interaction. Cutting away many attributes, many helper classes, many other things.
That can lead to pictures which are quick to grasp and then allow further digging based on code.
Also, class diagrams are more useful when you can’t give out source.
That being said, I think you can autogenerate class diagrams from code so it’s not like you should spend a lot of time making them.
In terms of artifacts for future maintainers? Maybe not as helpful. As previous posters have mentioned, the diagrams go stale very quickly if the engineering department isn't disciplined about keeping documentation up to date. But this is true for any documentation.
Some diagrams (class and activity, in particular) are less valuable as time passes. I can get the idea of the class structure by just looking at the code itself. The class diagram just ends up being a stale representation of the code.
It is unfortunate that UML has developed a reputation as being overly complex. Now I see more ad-hoc diagrams being created, with whatever notation/symbols make sense to author, rather than using a common diagram system that can be read by many.
It wasn't also visual design tools that Agile killed. Agile killed design documentation altogether.
With Agile, today's problems are addressed on tomorrow's sprint, and changes in software architecture take place only in the code. Any effort to document the system architecture in any remotely rigorous way is quickly deprecated, and teams simply don't waste time maintaining something that might already be deprecated once they finish editing the document.
I do really wonder why UML is still taught in universities, as the article states, it's pretty useless. I took a masters Software Engineering course at Georgia Tech two years ago and a big part of the class was learning UML. That time was mostly wasted as I've never used any of it and never met anyone who has used it.
It wasn't my first time learning it either, we also had a section on it in my undergrad software engineering course. So I learned the same useless stuff twice.
- 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 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.
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?
- University professors who remain exclusively in academia missed the rising tide and teach what they know
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.
So it is well worth 1 hour or 2 to look at it.
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.
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.
Deleted Comment
yep. kids out of college feel most inclined to use 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?
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
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.
Does that mean something? Besides you saying you worked in them? It’s a question ; I don’t know.
Dead Comment
Fundamental Modeling Concepts http://fmc-modeling.org/
Used consistently it really helps a lingua franca across teams. Which was the UML aim all along, but it got caught in into "Enterprise Bloat" (like SOAP or XML)
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.
Lots of people make bad designs today, sure, but it's not for a lack of formal methodologies, because average design quality was way worse back in the design patterns 'n' UML days.
For anyone who didn't live through that time, the Open-Closed Principle states that software should be open for extension, but closed for modification.
However, you could also rephrase that principle to be: 'you should always prematurely abstract your designs'.
I think if abstraction was viewed as a negative to be avoided unless necessary, software architecture would have been far better off.
To be fair, premature abstraction is a lot of fun for those that do it. It's just those that follow who aren't so keen.
DDD Europe by all accounts was a resounding success. We’ve replaced older architecture activities like data modeling first with event modeling and Domain-Driven Design.
We’ve learned to embrace monoliths when appropriate and reduce complexity with bounded contexts.
We have phenomenal testing capabilities that didn’t exist 20 years ago.
We have a myriad of data storage tools.
We understand front-end engineering from an information architecture perspective.
We can design detailed architectures in tools like LucidChart very quickly with detailed solution details.
I’ve been at this for 40 years and I’ve never felt better about being a software architect.
That sentence is bringing back ptsd-like flashbacks.
I remember distinctly how much everyone thought that approach you describe was broken when it was the trendy thing.
I'm not sure how universal it ever was, but it was at one point a trendy thing that everyone thought they should be doing... and that so many people subject to found disastrous. [The phrase "architecture astronaut" was a common epithet, and not a friendly one]
That above paragraph [without the brackets], ironically, could certainly be said of "agile" more recently too. I don't know how universal it ever was, but it was at one point a trendy thing that everyone thought they should be doing... and that so many people subject to found disastrous.
But yeah, I'm pretty convinced going back to appointing some almighty deity architecture astronaut who isn't responsible for or involved in any implementation (let alone operations!), who hands down plans from on high after "memorizing all design patterns" and drafting some diagrams, never sullied by "contact with the enemy"... no thank you, but thank you.
----
Instead of just complaining about that though, what I'll say in addition is -- I think the real problem is that engineers aren't given the time to carefully consider top-level designs. it's a basic business/resource issue -- until engineers have more breathing room to talk to each other and research and consider and come to decisions in an unhurried way, the top-level design stuff will remain chaotic. It's not an issue of appointing an ivory tower "architect", or something solved by it.
Although sure, there should be senior and even "staff" or "principal" people with more authority/responsibility for higher-level designs.
Everyone should be responsible for design at the level they are working. Everyone needs enough time to feel like they are doing it well, instead of running on a sweatshop code production treadmill.
If I went through and inspected any Node, Rails, Django, etc app I would find many Gang of Four design patterns, but very few of them would be in the project-specific code. They got implemented well, and now programmers can build new things that would have taken too long to do before.
And that was the intent of the Gang of Four book, not to teach you patterns you should copy mindlessly, but to give examples of how to identify and extract useful patterns from the software you've already written and describe them to others. Since that is a lot more difficult than memorization, very few took up that work.
That said, I've been at places where management did a pretty good job of making sure that there was enough time to do this kind of work with middling results. People have to enjoy the work or feel invested in a way that makes them care about "3 years from now", and sadly in a lot of places there's a lot of "whatever, it'll be fine for as long as I work here."
It seemed to me that in let's say 50% of cases, having the extra time didn't really matter. Assumptions about what was being built were proven incorrect not long after a design was laid down and work had begun, or particular engineering types would create increasingly complicated designs with their time rather than doing the hard work of distilling the problem, sometimes including $PET_TECHNOLOGY as part of their solution.
The "let's design something truly great" really has to be in a team's DNA in my experience or you wind up with a good design that isn't followed, one person who does all the work, a gold plated design, etc.
Like many abandoned corporate practices, I think it was abandoned for good reason. It may have made sense under different circumstances, like when you had a large army of cheap offshore devs who could not be trusted to architect a maintainable application.
If I had some ivory tower “architect” trying to interfere with my work I’d be so pissed. Anybody I’ve seen with that title, that wasn’t doing 1P cloud consulting where the title means something different, usually had no clue what they were doing and had been given the title as a soft retirement.
It is pretty funny when somebody runs into me and realizes for the first time that I have the job because I build stuff and write code, not because I'm good at LucidChart. I'm planning things out beyond immediate needs, but not because I'm looking for job security--it's because I've built the thing we're doing before and would like to not make the same mistakes I've made in the past. I'm over here demanding adequate standards of code and low- to mid-level design, and the "wait he's serious?" of it is sometimes honestly pretty fun to run up against.
I am good at LucidChart though.
I think what many people, esp. from outside the SWE world, don't get: Software engineering is a deeply social kind of work. There are dozens of solutions for the given problems, you have to agree on one that works for all peers. That's the job. Optimizing it for drawing funny diagrams is not an issue if not for communication.
This wastes a huge amount of time and usually the documents become obsolete as soon as you try to actually run some code.
This is the very issue the Agile manifesto identifies and proposes a solution to when it says "working software over comprehensive documentation". 'Comprehensive' is a key word as they don't mean NO documentation but effectively just what's needed to plan and help people understand the code.
I do however agree that design is sorely missing from the current software project management zeitgeist, which means it’s done in a more ad hoc way. People are taking frameworks like Scrum far too literally, and I agree that in some cases there is little vision or overall architecture because the framework doesn’t include these things. There should be design and review activities both before and after coding, but these are largely neglected from most project management frameworks. Scrum for example doesn’t even include backlog management, which in my work is a critical activity.
While that doesn’t mean design, architecture and scope management is not done, it’s certainly less visible than it might be.
All of that said, I’m a big believer that the ultimate expression of any design is code. The design artefacts that come before code is written are scaffolding, age quickly, and are soon useless. So there’s not much need to keep them around, and they are mostly of interest as preliminary directions.
In this regard I’m a big fan of Jack Reeves essays from the same period at https://www.developerdotstar.com/mag/articles/reeves_design_...
And thank goodness. I am all in favor of more consideration, more quality, more integrity. I like good architecture. But I think it's a giant mistake to create a software architect role. Every company where I saw that in practice, the average architect was a bloviator who did no actual work but was very excited to tell everybody else how to work.
At the code level, this resulted in a lot of messes. The edicts and white papers sounded good in theory to the kind of people who decided the bonuses of the architects. But frequently they were unworkable in practice, causing a lot of code that conformed to the theory but was a pain to actually deal with.
I agree with you that a lot of things are half-assed and rushed, of course. But we are never going back to a world of 18-36 month release cycles where people could stroke their chins for a quarter or two before building anything. Instead, we need to move in the direction of continually investing in quality, so that the design of systems improves over time. Something that I think is actually easier, in that waterfall design practices locked in important decisions early on, when people knew the least.
The same market that gave us AT&T, Comcast, DRMed IoT Juice presses, FTX, Enron, and so on? Not sure it’s wise to conclude that the market produces optimal solutions, or even incrementally better solutions than yesterday. Especially in domains with extremely long feedback cycles, like organizational trends.
I DO think there is some hocus pocus market zeitgeist that does something resembling gradient descent, but it’s acting over very long cycles and there’s a ton of room for cargo culting, grifting, and opportunistic grabs along the way. Heck, marketing is an entire field dedicated to affecting “rational actors” in the marketplace.
On the other hand, Boeing's crappy software practices resulting in the 737-MAX crashes are an area where short-cuts killed people.
The risk and complexity dictate how much architecture and engineering are involved and with all things, businesses will try to get by with a bare minimum. The automotive, chemical, and other industrial sectors invest a lot in software architecture and enterprise architecture because the risk is so high. But even a medium size e-commerce platform has very low risk or complexity.
i prefer to reason about a system and component relationships using, say, a single word as representation, instead of glaring at one or many inheritance directionals, interface details, and other "field" information, which is usually conveyed in a UML node.
i do not think the lack of formalism is a degradation -- we work with abstractions after-all, so it makes sense to further leverage that fact and express things simply, at a high-level, and straight-forwardly -- you can pack a lot into a single word.
of course as the nature of any tool, there is a time and a place for its application. but i don't think it is fair to call it a degradation.
I agree. I don't personally fetishize the old slow processes nor ivory tower architectures, but I think there's a healthy spectrum between that and the complete 'software fuckery' (https://web.archive.org/web/20160308032127/https://medium.co...)
What we should do is probably in your advanced data structure programming course that everyone has to take is to create a model of an elevator and diagram the behavior using a sequence diagrams. This would be achieved by using an associative array AKA a map [1] that would represent where the elevator is and what it has to do next (current state and next state based on input).
If you program this correctly it gets around using unit testing even because you have diagramed and all parts of the system are known and can just be gone through and that would be a sufficient test. An example of a library that implements this is at https://pypi.org/project/python-statemachine/
[1] https://en.wikipedia.org/wiki/Associative_array
- There's very high-level engineering occurring ('computer science'). I always assumed this would be at places with 'web-scale' problems, but I've been seeing amazing work in local (not-web-scale) product companies here in Australia.
- On the other hand, I think a lot of other development work is not much above building flat-pack furniture. I guess this is where lo/no-code solutions will thrive
The important thing is to recognise which is being done, and which practices apply each case.
The project management triangle never stopped existing.
I was eager to use UML when it came out but I agree with the article, the only thing I kept was sequence diagrams. Most of the rest of it was just a complicated way to represent stuff that is best represented in code or plain documentation.
I’m also not afraid to use stuff that’s out of fashion. I use simplified ER diagrams, and even flow charts on occasion.
But the tool I use most often in design is SQL DDL…
I have also used Mermaid (using a modified Docsy theme in Hugo) and it is also great. Using Typora to edit Mermaid is also excellent.
Teams aren't shunning design. They're just doing it incrementally, because as it turns out, trying to design a piece of software before the first line of code is written doesn't actually work.
Even in peak UML (2000 or so) there were no really practical UML diagramming tools. (Rational Rose was impractically expensive, and buggy enough that it was a race to see if it wouldn't crash before you actually finished your diagram).
Corel Draw had passable UML diagraming support. But I don't imagine it still does.
Draw the boxes and lines and make sure that people understand what they mean. Describe the system from the perspective of the reader. Just like a real architect will have different drawings/plans/elevations for their customer, the planning authorities, and the builder.
The architecture diagrams are meant to communicate the design, not comply with some over-worked standard.
UML was a clusterfuck that evolved from the trifecta of late 90s OOP (inheritance not composition), design patterns that mostly provided fill-ins for what was missing from Java as a language, the ridiculous concepts of generating code from diagrams that could be regenerated from code, which never, ever, worked, in the same way that ORMs have an impedance mismatch between OO and relational logic.
It was yet another silver bullet, the late 70s/early 80s had "structured programming", the late 80s/early 90s had CASE, the 90s had all the stupid diagramming tools where people argued about the shape of the bubbles and what arrows to put on the lines.
There was also the Capability Maturity Model, where everyone was trying to get to "Level 5" which was only useful if you were doing exactly the same software over and over again, along with the "6 Sigma" and "Black Belt" nonsense.
The 2000s had the "iterative Rational Unified Process" (an excuse to sell expensive tools from IBM), along with CORBA et al.
The last decade has suffered from the Agile-with-a-capital-A and especially "Scaled Agile" which is just an excuse for project managers to again treat programmers as fungible, while losing all of the affordances of actual project management, like GANTT, critical path, S curves, earned value etc.
Sprints are nonsense, so is "t shirt" sizing and velocity and burn down charts, and retrospectives and scrum "masters".
There are a couple of useful things:
* Domain Driven Design, using Names That Make Sense To The Customer
* Entity Relationship Diagrams, where the Entities are the same Names as the DDD
* State Diagrams for those Entities, describing the events that will cause them to change state
* Event definitions that match the State Diagram transitions, where externally generated events end up being your external API.
Bah, I've been in this industry for almost 40 years and its the same shit over and over, just with different names, and different consultants selling expensive courses.
Deleted Comment
Having lived through both, modern development practice is superior in practically every way, most especially with respect to quality.
The problem with Heavy Development Methodologies is that they didn't actually work.
I have a blog post in the works about this but it's not ready to share; in short, I can't help but notice that hyper-focused, optimize-for-time-to-market, minimum-viable-product projects have a real, and frequently killer, problem once you have built your initial, hopefully-better mousetrap. Almost every company I've ever worked for has gotten that initial mousetrap done, tried to expand horizontally to actually have enough stuff-that-works-together to actually sell, and fallen on their faces because that initial super-specific development effort created not just code, but product assumptions that are prohibitive to unwind.
Most of them hit the hillside because reality is no longer playing ball with their (frequently VC-driven) needs to cut scope and ship.
Another useful chart type provided by Mermaid.js is the git diagram, which I use all the time when brainstorming change processes, especially for other folks who might not be git-conversant.
https://mermaid.js.org/syntax/gitgraph.html
Out of these text-to-diagram tools, D2's syntax seems the friendliest to me. See https://text-to-diagram.com/.
One thing that worries me is that the profusion of text-based graph description languages will result in a family of software that's unparseable due to its success. We have Graphviz, GNUplot, PlantUML, BlockDiag, Mermaid, Kroki, Vega, and too many others to count - but we don't have a Pandoc.
Before UML, there were many methodologies. UML was started by a unified team of some of the most noted OO methodologists.
There was a lot of good thinking, but one of the adoption problems we had before UML (as tools developers and methodologists) was that many people got a poor introduction to it, and missed the whole point.
For example, on a diagram metamodel that emphasized formalizing and visualizing the relationships among objects... some people would think it was a TPS Cover Sheet task, to laboriously draw their class inheritance hierarchy and summarize their attributes and method signatures, for purely corporate bureaucratic reasons.
You could also contrast people who needed to build complex embedded system behavior, for whom Statecharts were a very valuable tool for keeping the model manageable -- distinguished from people who were told to do it when it wasn't appropriate, and they just kinda tried to document their code control flow by misusing that same diagram notation.
Today, I can't blame people for not understanding, since most examples they'll now see are incorrect noise, and the current UML spec itself doesn't do this reputation any favors.
Half-seriously, maybe we could use a reset, in which people who neither know or care what they're doing stop being required to go through the motions of pretending to do it. Also stop trying to have people who don't actually use it teach it to students who just want a good grade in the class (for their FAANG job application), and who have little-to-no experience necessary to appreciate the real thing. Also don't make it a marketable resume keyword. Then the only people who will be doing or talking about it are people who care enough to figure out the genuine merits, with no incentive to pretend.
Then, ideally, the only time others will see it is when someone whips out a formalized diagram for something complicated, and proceeds to start explaining it by walking the audience through the diagram... Some people in the audience will get the tingles, as they're not only understanding, but they're also sensing a very powerful modeling tool that would address some problems that they and their team have in their work. (Realistically, this would start to happen, but as soon as it becomes a resume keyword or interview ritual, history would repeat, but maybe that time with a larger mitigating mass of people who understand and appreciate.)
Not really, UML was doomed from start due to increased time to market metric. And frankly you can read the code if you are working on the already built system. Remember that software usually does not need to be correct, or even well designed to support a business case. It is one of software greatest strengths and weaknesses compared to other disciplines.
It does helps in some integration tasks, and works decently as schema definition language that's format agnostic.
I'll also concede that state diagrams are good, but well.. they are also quite simple.
Then there's readability issue - unless you worked tons with UML you WILL make mistakes when it comes to object relationship counts, and there's a lot of other non-obvious gotchas for newcomers(i used to teach reading entity relationship diagrams to non-technical people so they could understand the model they were working with, as it was a part of legal bill).
Not to mention that only proponents of UML that i've personally met, were people who were stuck in academia, and never worked on any real software product..
And even for R&D work on a harder problems it's usually easier to write a toy side project and test solutions.
Code you write in such toy project IS an entity relationship model. Tests, and example usage is a happy path of sequence. etc.
> I'll also concede that state diagrams are good, but well.. they are also quite simple.
One of the goals of state modeling is to simplify. A sufficient metamodel will include (in addition to states and transitions on events that people might see in automata theory and misc. CS education) less-simple features like concurrency, superstates, transition guards, maybe real-time constraints.
When you need a nontrivial system to actually work, in all cases, (not just toss your sprint task over the wall, and then do bug tasks later) good use of the abstractions of this "simple" diagram, and inspecting it, will tend to avert problems that even an unusually conscientious programmer might miss in just code. And it also helps communicate less-ambiguously to others who come later and need to evolve the code. Unlike formal proofs, it's pretty accessible to read.
(It can be too accessible, in that people who are accustomed to seeing hand-wavy business diagrams with ad hoc notation used inconsistently think they also get the gist of this diagram, while not realizing how much more rigorous it is. But that's not a big problem -- you just have to walk them through it, ask questions to confirm facts expressed, emphasize when something has to be precise and exhaustive, etc. The problems are more when the diagram is poor, yet the technical appearance confers an undeserved aura of respectability, and people who can't tell the difference, act on that, but that's not unique to these diagrams.)
I've seen people spend days and days trying to save a few hours of paper design time.
We often do quick paper or marker board designs, which often have some UML. You don't want to spend more than 10% of your time on this, but it can save quite a bit of time to market. If someone really wants the design saved somewhere, we just take a pic and upload it.
But the reality is that an awful lot of the software we build just isn't complex enough to warrant all this ceremony. It's not branchy, there's no significant error handling to talk about, no big new dependencies being added, no security implications, no long-term maintenance of an external interface— it's just grabbing widgets from pile A, frobnicating them, and dropping them on pile B. There's barely enough there to even unit test much less write a "design doc" about and agonize over in a meeting with bigwigs.
And unfortunately a lot of the projects that junior developers start out with look exactly like this. Boring, obvious code that does one thing in the exact boring, obvious way that you'd expect. So it's easy to fall out of the habit of thinking intentionally about design, until you're suddenly faced with a big thorny problem that legitimately has multiple paths forward, and what starts as a rubber-duck conversation with the person beside you eventually becomes "hmm... I think I need to write down a page or two that describes these options, gives background on why the choice matters, describes why the selection was made that was made; then maybe afterward I'll circulate that document to my colleagues for their review and thumbs-up, because maybe there's something I'm overlooking here that they could contribute to?"
Oh wait.
significantly more interesting technological failures deserve dibs on this excuse
I'm addressing the masses of us Webrogrammers, who classify all that space as "UML", and dismiss it. Not everyone is just going to be tossing (ChatGPT-assisted) sprint tasks over the wall, while calculating when to make their next job hop. Some teams will have to build complex things that work, and they can benefit from informed and judicious use of abstractions and views on the system.
Undergraduate students probably don't have the experience and design maturity to fully appreciate when and how to use most UML diagrams. I think you need to get stuck at design problems a few times before you can appreciate the need to capture ideas using the right diagram, and then you might be ready to adopt some standard so you can share your design decisions with others in a way that correctly captures and conveys just the right amount of detail.
The challenge comes when trying to document the entirety of the system, and keep that up to date. The overhead is too high and complexity is such that it defeats the value of a model used to communicate shared understanding.
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.
UML. Use what you need, but need what you use.
Come to think of it, that probably applies to abstraction. And threads. And probably several other things.
The only organizations using UML were bureaucratic heavy nightmare places to work too.
[0] https://www.rfc-editor.org/rfc/rfc793
Edit: there are a form of sequence diagram in an early FTP specification from 1971: https://www.rfc-editor.org/rfc/rfc172.html
Neither does "Ericsson Approach" for that matter..
I still think it is great. People who never learned about UML tend to reinvent some such thing when they wish to communicate the same structures and information.
Then you end up with 10 different people drawing approximately the same information in 10 different forms, and all will require some level of explanation of notation and grammar for others to grok it.
A class diagram can contain a lot of rather valuable information.
I do agree that sequence diagrams are great, but if you rip them out of context and throw the rest in the bin it can only partially communicate, whereas if you had the object model to study as well as the sequence diagrams new connections can be quickly made.
To this day I prefer to create my object structures in a UML diagram. Plenty of software takes it creates the code, or takes the code and produces the diagram.
I love creating the diagram(s) when I first start working on an existing system.
What I have seen of code generation off of sequence diagrams have bit hit or miss. more miss. But reverse engineering sequence diagrams can be quite revealing.
And C4 diagrams are great for explaining software architecture, which wouldn't have been possible without UML and esp. class diagrams.