> It is perhaps unfortunate that no design (sorry, “emergent” design) is the best practice that has replaced it.
I can't really agree with this. I design and build very large scale systems. We don't use UML, but it's possible to rigorously design and plan without UML.
Our designs are typically made of JSON data models, operations that take and return those models, and sequence diagrams that show the temporal relationship of the operations. It's not fancy, but it's dead simple, still pretty rigorous, but not too rigorous. Our implementations end up looking pretty much exactly like what we planned (even though they aren't actually JSON), and anyone can read and understand them.
Sometimes we build critical systems that require very rigorous design, to the point where we use TLA+ to catch design flaws. And sometimes it's just some internal UI and we slap together a bunch of random stuff haphazardly. And various degrees in between. I wouldn't characterize the "best practice" as "never design", it's more like "design, but not too much". UML is usually "too much", or places the focus on things that don't really matter.
(Note, I don't have much experience with UML, I dipped my toes in it a long time ago and ran away screaming.)
Yeah. "Rigor of the design" and "medium of expression of the design" are two independent axes. You can have a sloppy design expressed in UML, or you can have a rigorous design expressed in UML. Or you can have a sloppy or rigorous design expressed in something else.
The question then is: Is UML a good notation for expressing designs? And I think the general consensus is, "no". It's too high-ceremony for how much it aids communication.
And if you're going really rigorous, well, I'm going to guess that TLA+ doesn't read UML diagrams...
> UML is usually "too much", or places the focus on things that don't really matter.
Design is important where separate teams and systems interface. It's less important when a team understands the system well. That's what class diagrams aren't very useful. That, and I can explore them in my IDE, and really, complex class hierarchies are a smell that something's over-engineered.
Design your API like you’re expecting to be the next Stripe. Then add a little more context. You’ll never get recognized but your documentation will be amazing.
Think: “how am I proactively planning on getting promoted so I can forget all this?”
It's unfortunate that the customization of UML is not more accessible. This could cover exactly the use case "a reduced, specialized subset" with full editor support.
May I ask where you work? Leslie Lamport has been asking around for examples of companies using TLA+ internally; he'd be interested in hearing your story.
I can't really agree with this. I design and build very large scale systems. We don't use UML, but it's possible to rigorously design and plan without UML.
Our designs are typically made of JSON data models, operations that take and return those models, and sequence diagrams that show the temporal relationship of the operations. It's not fancy, but it's dead simple, still pretty rigorous, but not too rigorous. Our implementations end up looking pretty much exactly like what we planned (even though they aren't actually JSON), and anyone can read and understand them.
Sometimes we build critical systems that require very rigorous design, to the point where we use TLA+ to catch design flaws. And sometimes it's just some internal UI and we slap together a bunch of random stuff haphazardly. And various degrees in between. I wouldn't characterize the "best practice" as "never design", it's more like "design, but not too much". UML is usually "too much", or places the focus on things that don't really matter.
(Note, I don't have much experience with UML, I dipped my toes in it a long time ago and ran away screaming.)