Thread by @simonbrown

"Can Formal Methods Succeed where UML Failed?"

No.

"People didn’t switch from UML to something else; they walked away from the mindset entirely. UML wasn’t fulfilling a meaningful use case for programmers, so when it didn’t work they didn’t look for an alternative."

Disagree.

I do believe that agile and the associated cultural shifts had a much larger influence on UML's decline than anything else. With a quick glance, sure, UML seems too detailed, too complicated, the tooling sucks, etc.

But I've run diagramming workshops at organisations across the globe, for organisations of all sizes, 10K+ people. Most of the orgs have explicitly told me why they dropped UML ... this is covered in my @yow_conf "The lost art of software design" talk

"We're agile", "it's not expected in agile", "we don't want to tell developers what to do", "you'll be seen as old-fashioned" are the types of reasons cited for teams dropping UML.

Yes, I know they don't make sense. And that's the point.

"People didn’t switch from UML to something else; they walked away from the mindset entirely. UML wasn’t fulfilling a meaningful use case for programmers".

There's some truth here. Back in the late 90's, as now, class and sequence diagrams were the most popular diagram types.

And developers were often asked to draw out these diagrams before writing code. Remember the "document your proposed design and write manual test cases" days?

With the shift to "agile", teams realised that working this way was inefficient, and replaced this document-driven design activity with automated testing, TDD, and pairing.

A major use case for UML was gone. Architects were still using it to describe higher level abstractions, and for documentation. Teams reducing their up front design efforts and "we value working software over comprehensive documentation" eventually eroded those use cases too.

Prominent agile evangelists were literally telling people that they didn't need UML; example -> ronjeffries.com/xprog/articles…

There was also a big "we don't need architects" movement after the introduction of the agile manifesto, further pushing up front design, documentation, UML, etc into the background.

Sidenote: I've had many conversations with architects in larger organisations who have told me they felt very excluded during these times. As we all know though, a team unit still needs those architecture skills. It can't be "full-stack" without them.

"they didn’t look for an alternative"

Teams *are* looking for alternatives. I've been running diagramming/documentation workshops for the past 10+ years. Teams have been slowly realising that having no documentation is a bad thing ... even before the COVID-19 pandemic.

I've heard all of the stories ... no standard communication method inside/outside of teams, duplicated/wasted effort, onboarding new staff difficult, codebases a mess because developers have different views of how it works, etc.

A good solution is "just write some documentation and use UML". It's crazy, but teams do *not* want to do that. They are literally shunning UML because of stories they've heard (many developers are no longer even taught UML at university, etc) or fashion/cultural expectations.

This goes back well over a decade now. My original software architecture workshops were more design focussed, but I noticed that teams couldn't visualise their designs. "UML was bad", so they used ad hoc whiteboard sketches instead.

This is why I formalised the way I diagrammed software systems with the C4 model. Teams were averse to using UML (for "reasons"), but I saw that they lacked structure, which led to their diagrams being ambiguous and incomprehensible.

It seemed that the concept of a "standard notation" bothered people, so I focussed on a small common set of abstractions and suggested that "any notation is okay provided it's defined in a key/legend".

The C4 model is notation independent, and you can definitely draw those diagrams using UML. But almost nobody does that. You should ask them why.

So teams *are* looking for alternatives, and in many cases they've found it. The C4 model covers the majority of what many teams need: static structure at the higher level abstractions, runtime/behaviour, and deployment.

It's 4+1 with some tweaks, in a notation independent way.

"Can Formal Methods Succeed where UML Failed?"

I don't believe so. I only see formal methods being used by teams in highly regulated environments. Granted this isn't my core client base but, in my experience, formal methods are in even lower usage than UML.