[biofox]

The challenge is getting software engineers to learn and use UML properly. As a discipline, we seem to be in a perpetual state of reinventing the wheel, when we have plenty of mature tools and established best practices that people don't care to learn.

[decasia]

I have to confess I am guilty of this — I used to just draw some unstructured circles and arrows on a whiteboard and call it enough.

Lately I've been trying to work my way through lots of different diagram types from https://plantuml.com/, and it does help to wrap my mind around the existing options.

[friendzis]

A related issue that we, software engineering people, ignore the design-implement workflow other engineering areas successfully use, mainly because that is not agile enoughtm.

Unless teams are bound by some ISO to have design documentation timestamped earlier than feature DoD, engineering process gets flipped on its head and design docs are quite likely to be simply braindumps of some uninterested party rather than formal-ish specifications driving the implementation.

> when we have plenty of mature tools and established best practices that people don't care to learn.

Hyper-fixation on agile and "move fast and break things" attitude is in part to blame here. You can't really put a timebox on "learn how to use mature tooling" or storypoint "design architecture", when only implementation is rewarded.

[photonthug]

There’s truth in what you say and UML has some good ideas, but it’s not the one true way. One problem with it is that even if engineers can read it properly, diagrams often need to do several jobs at once, and communicate something to non-engineers, otherwise you are making diagrams all day!

[opello]

The various times I've encountered effective UML, it's been an organization's take on how to use it. I can't remember if the UML Distilled book references this kind of dialectic use but it seems like the only way I've seen buy-in for use and maintaining the diagrams as documentation.