Use cases, activity diagrams, deployment diagrams etc.
Yeah - 'informal' UML use a lot of people are happy with but some things like exactly what some of the features of activity diagrams mean is amazingly badly understood by a lot of people.
I'm ok with the 'UML as sketch' approach, but 'UML as blueprint' is a nightmare that I've never seen work:
Honestly, most of the time I use these diagrams just to give people the gist of what I'm talking about. And my diagrams are super low effort. Think low effort whiteboard diagrams during a meeting style.
> Yeah - 'informal' UML use a lot of people are happy with but some things like exactly what some of the features of activity diagrams mean is amazingly badly understood by a lot of people.
Same with frontend, I give a very rough wireframe trying to translate wtf they are telling me. The end result usually looks very different because once you flesh stuff out IRL there is always a bunch of hills to climb that were unanticipated. And that’s why it always takes 2-3x longer than we first thought.
Especially in a large application with lots of moving and breakable critical parts.
The only solution is constant feedback loops and not being bummed out when your code goes in the dustbin.
Use cases, activity diagrams, deployment diagrams etc.
Yeah - 'informal' UML use a lot of people are happy with but some things like exactly what some of the features of activity diagrams mean is amazingly badly understood by a lot of people.
I'm ok with the 'UML as sketch' approach, but 'UML as blueprint' is a nightmare that I've never seen work:
https://martinfowler.com/bliki/UmlAsSketch.html