"Can Formal Methods Succeed where UML Failed?"


"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."

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.

• • •

Missing some Tweet in this thread? You can try to force a refresh

Keep Current with Simon Brown

Simon Brown Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!


Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @simonbrown

11 Jun 20
I'm prototyping a textual DSL for creating @structurizr models, which currently looks like this...
That DSL fragment describes a number of people and software systems, plus the relationships between them. It doesn't specify any diagrams though. But, using some conventions (for example, "if no diagrams are defined"), we could create them automatically.
In this example, it's possible to automatically create 5 diagrams, based upon the underlying model:

- 1 x System Landscape (showing all people and software systems)
- 4 x System Context diagrams (one for each software system, showing nearest neighbours).
Read 5 tweets
22 Apr 20
Indeed! I also don't think that many teams really understand what their codebase looks like...
I've run a number of workshops where I've asked teams to draw software architecture diagrams of their own software. In many cases, you get the typical layered architecture, with all of the arrows pointing downwards (a strictly layered architecture).
Me: that looks lovely; is your codebase really that well structured?
Team: yes
Read 7 tweets
22 Apr 20
One of the reasons is the "model-code gap", as described by @GHFairbanks in his book...
Ever tried to automatically create a diagram from code? It doesn't work well, because the tooling is essentially just reflecting what it sees in the code.
Here's an example - it's an old version of the @springframework PetClinic application. If you load the code into an IDE, and ask it to create a diagram, you'll get something like this.
Read 22 tweets
18 Apr 20
And here are some options for your consideration ... or inspiration. (thread)
First up ... @adrianco created some tooling a while back, which provides an interactive visualisation -> github.com/adrianco/spigo
Then we have @terrastruct, which allows you to add "layers" to your diagrams, making it possible to zoom in to show more detail (click the "Web Server" box) -> app.terrastruct.com/diagrams/10764…
Read 9 tweets
2 Feb 19
I’ve had this a number of times recently ... “we’d like to invite you to do a private talk for our staff ... other speakers generally do this for free because it’s good for exposure”.
I will happily speak at a public meetup for free if I’m already in the area. Asking me to undertake an unpaid 2-3 day roundtrip to do a free private hour long talk for your staff is pretty offensive though.
Sometimes companies will ask me to visit them for free when I’m “in the area”. The problem here is that often a competitor company is paying me to be in the area! So that’s not very fair on my clients, who are often smaller companies than those asking for free stuff.
Read 9 tweets
20 Jan 19
Some good stuff here, although there is still room for more details on the example diagrams ... technology choices, relationship intent, etc.
e.g. “why is the ABC Financial System communicating with the Analytics system?”
“What technologies are the various microservices built from?”
Read 7 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!