April 27, 2021

Why UML "Really" Died

There's this post going around the internet called Has UML died without anyone noticing?, In the piece, Ernesto Garbarino says that UML was killed by decreasing standards among programmers: "Agile was the assassin and user stories were her deadly, poisonous arrow heads (pun intended)." If there's one theme of this newsletter, it's that we shouldn't trust simple answers. The real world is complicated.

As it happens, a few years back I was planning on writing a history of UML: where it came from, why it got so popular so fast, why it died, etc. As part of it I interviewed a bunch of prominent people from the early days, including Grady Booch, Bertrand Meyer, and Ed Seidewitz. The project ended up dying and I threw it in the graveyard if you want to read how far I got before I gave up. But I still remember bits and bobs, enough to confidently say that no, the story is a lot more complicated than "Agile did it". Disclaimer, I'm running off my memory and illegible notes of a project I abandoned four years ago, so I'm probably getting some of the details wrong.

Prehistory

Two important trends lead up to UML. The first was the Method Wars. After Smalltalk and C++ mainstreamed OOP people got really hyped about finally creating formal, unified processes for designing software systems. This started an explosion of different design methods. In his book on Business Object Notation, Bertrand Meyer lists twenty-six competing methods. I remember reading documents that listed over fifty, but I can't seem to find them again so it might be a false memory.

Around the same time people were also making the first Computer Aided Software Engineering (CASE) tools. CASE is barely a footnote now but at the time was a huge industry, expected to be much bigger than CAD or IDEs. CASE tools integrated with methods to provide a holistic means of creating software, not just for developers but for testers, project managers, and clients. Making CASE tools was expensive, though, and had to be tailored to a particular design method. Over time, CASE vendors settled on three:

• Grady Booch's Object-Oriented Analysis and Design¹
• Ivar Jacobson's Object-Oriented Software Engineering
• James Rumbaugh's Object Modeling Technique

Grady Booch worked for Rational, which also had major CASE chops—they made most of their money off Ada tooling. Booch also was personal friends with Rumbaugh, and over time their ideas converged. After a point, this put a lot of pressure on them to explicitly collaborate so that CASE vendors had to support only two methods instead of three. Then, because one method is better than two, they bought Jacobson's consulting company and phased out OOSE.

OOSE, OOAD, and OMT were holistic methods, covering both notation and process. It's easier to smooth out differences in notation than differences in process, so Rational broke unification into two parts. The Unified Modeling Language came out in 1996 and was turned over to the Object Management Group (OMG), and Rational Unified Process came out in 1997ish. UML proved extremely popular for about a decade and started a long decline in mindshare circa 2004 until today, when we're publishing articles like "has UML died???" So why did UML die?

What does that mean?

There's two ambiguities in that question. First is what we mean by "die". Often programmers use "die" to mean "decline in relative marketshare", not absolute marketshare. Lots of Thought Leaderz bemoan how few devs understand really low-level systems anymore, but there are more kernel hackers in total than there were 30 years ago. They're just a lower percentage of all developers. This means that UML can be growing and "dying" simultaneously, depending on what metric you use. I'll assume for now that UML is unambiguously "dying", even if that's not necessarily warranted, so I can discuss more interesting things.

The other ambiguity is what we mean by UML. First of all, UML consists of over a dozen different diagram types.² I still see people regularly use sequence diagrams. Second, there's many different ways people use UML diagrams. Martin Fowler, a prominent figure in both the UML and Agile worlds,³ identifies three types of uses: sketching, blueprinting, and programming.

Two of these are easily enough to explain. UML-as-programming died in infancy because even most proponents of UML considered it a terrible idea. UML-as-sketching didn't so much die as drift. There was nothing that kept people's informal sketch notations in sync with the UML standard, so over time it drifted into multiple, mutually unintelligible dialects. I wouldn't expect two teams in different companies, one in California and the other in New York, to use similar notations unless someone was deliberately keeping them in sync.

This leaves UML-as-blueprint as the most complex case. To my understanding, it's also the one most intended by Rational. There are two relevant differences between UML-as-blueprint and UML-as-sketch. First of all, the intent was for a designer to write the blueprint and a programmer to implement them. This meant different skills and different tools. Second, UML-as-blueprint integrated the different diagram types. You wouldn't just write a class diagram and a requirements diagram, you'd write a class diagram for a class that implemented the requirements diagram. That meant using CASE tools for blueprinting. So the decline of UML is tied to the decline of CASE tools in general.⁴ This means that "why did CASE tools fail" is just as interesting to why UML-as-blueprint """died""" as issues with UML are.

Okay, enough preliminaries. Let's get into some of the reasons. This is not a comprehensive list; remember, I'm just running off memory here. And history, as always, is messy, and comprehensively listing "the reasons" is an exercise in futility. But it's still useful to see some of the factors.

The Reasons

Legacy Constraints

UML appeared after the method wars and the rise of CASE tooling. There was already a large number of CASE tools for OOAD, OOSA, and OMT on the market, and UML had to be backwards-compatible with all three. This added a lot of friction from the very start. UML could have been a lot simpler and more conceptually unified if it didn't have to deal with legacy vendors.

Lack of Formalization

UML left a lot of stuff unspecified, such as the ways the diagrams interacted and what a lot of the keywords actually meant. UML 1.3 gives an example of the "generalization" arrow in class diagrams, where Sailboat is a specialization of WindPoweredVehicle and WaterVehicle, which are both specializations of Vehicle. What does that actually mean, designwise? Are we supposed to implement it in a particular way, using inheritance, say? How does this different from a refinement relation? etc etc etc. In practice, users could decide what these relations meant, and CASE vendors could decide what features to implement.

This might remind you of C. The reason C89 has so much undefined and user-defined behavior is it needed to accommodate all of the conflicting compilers. OMG (the maintainers of UML post-1.0) had the same problem. They couldn't make any updates to the UML standard that would break existing vendor decisions, which further slowed down UML developments and added complexity to each revision.

IBM

This is some gossip I got from one of the peripheral people. at the time, while OMG was constrained by existing vendor differences, they had some leeway to make breaking changes for the Greater Good. I suspect that Rational, as the original developers of UML and one of the biggest CASE tooling vendors, was especially willing to update their legacy software. But then IBM bought Rational in 2003, and they quickly EOL'd Rational's UML tooling and started marketing Rational Software Architect, a proprietary CASE tool. Since they didn't want to continue developing the legacy Rational projects, they blocked any UML changes that were even slightly incompatible, and UML as a whole stagnated.

2003 is also roughly around when UML mindshare started to decline. I don't think the two things are a coincidence.

Too Complex

Now we're getting into the specific issues with UML. UML included many different diagrams and rules, leading to a very complicated end product. Everybody's bemoaned how hard this makes learning UML. This also makes developing tooling hard. You can get away with knowing only a few diagrams, but any tooling has to be comprehensive across the entire spec. If you wanted to build something more complex than "generate diagram" you needed a large team and a lot of money, which limits how much you can actually grow the ecosystem. There's not a whole lot of CASE tools coming out of open source, and the ones you do get are pretty piss-weak.

That's not to say that the commercial CASE tools could work miracles. The more complex your notation is the harder it is to develop any kind of tooling for it.⁵ UML could have lasted significantly longer if CASE tools were doing exciting, innovating stuff, but they weren't and it didn't.

No Text Format

This is yet another drag on tooling. It means you can't edit UML diagrams in your favorite text editor, or grep them, or write your own bespoke parser, or whatever.

There have been attempts to create textual representations for UML, like PlantUML or Mermaid, but these run into a couple of problems. First is that they're one-way only: you can't convert an existing diagram into the text form. The second issue is what I call the Graphviz Problem: textual formats are terrible at representing visual layout. At best you've got a cumbersome system that's significantly worse than using a graphical editor, at worst you're tweaking settings to make the layout engine play nice, at double worst you're writing TikZ.⁶

No Data Format at all

Sort of a corollary of No Text Format, but a problem for different reasons: the visual representation is the format and the only format. This made importing and exporting UML basically impossible. Once you started using a tool, you were stuck with that tool. Among the obvious problems, this is, yet again, an ecosystem killer. You couldn't make standalone UML tooling, your validator or whatever had to run as a CASE tool extension.

OMG tried to rectify this with XMI, an XML format for UML, but supposedly it never worked that well. And it was backwards-incompatible on both the XMI and UML versions, which made it exceptionally brittle.

No Roundtripping

Some tools could take some UML specifications and generate code from them. Some could reverse-engineer diagrams from certain code. None could do both well. UML and code would inevitably fall out of sync, as all blueprints do.

When interviewing UML users, this was the complaint that I heard most often. They thought that UML rotted too quickly to be useful.

Culture Shifts

One final, highly speculative reason. In the original article Garbarino said that UML died because Agile took over in the culture. I do think that cultural shifts played a role in UML's decline, but not for the reason he thinks.

CASE tooling only makes sense for large software projects, where you have a lot of people working on the same thing for a long time. It's also highly "bureaucratic". While we think today that Agile replaced a dominant Waterfall, at the time most developers worked ad-hoc and incrementally. For these reasons, it seems reasonable that CASE tooling was something primarily adopted by enterprises that mandated internal use. As Garbarino himself says, UML was loved by the business people, not the programmers.

Traditional enterprises were the dominant software employers in the 1990's, meaning that tech trends likely reflected their interests. That would be a good explanation for UML's initial rise. Over the past two decades, though, software culture shifted progressively towards large tech-first companies and startups. Neither, historically, was the target audience of CASE vendors. Over time traditional enterprise starts borrowing from tech and startups vs the other way around, leading to the progressive decline of CASE in its extant niches.

I want to be clear that this is all pure speculation. To really concretize it I'd need to look at market share by decade, who the main CASE clients were, who was driving those decisions, etc. But it's a believable enough explanation, and most of us are already familiar with this process causing enterprise adoption of microservices, agile, blockchains, etc. Something worth investigating if I ever pick up the history again.⁷

---

The original article was about 1100 words; this is over 2200. And while I'm running off half-forgotten memories, those are memories that came from hours of research and interviews. As much as I hate oversimplified explanations like "It died because Agile", I can totally understand why people write them! It's just a lot easier.

That's all from me. Enjoy your week!

Update for the Hacker News Crowd

This was sent as part of an email newsletter; you can subscribe here. Common topics are software history (like this one), formal methods, the theory of software engineering, and silly research dives. I also have a website where I put my more polished and heavily-edited writing; newsletter is more for off-the-cuff writing. Updates are at least 1x a week, though recently I've been pushing to do 2x. So there will probably be another essay Thurs or Fri.

If you're reading this on the web, you can subscribe here. Updates are once a week. My main website is here.

My new book, Logic for Programmers, is now in early access! Get it here.