6 ms·

'Culture Shifts' is the relevant bit. Orgs that realize a month's worth of planning to save a week's worth of dev work have realized UML isn't useful to them. O

'Culture Shifts' is the relevant bit. Orgs that realize a month's worth of planning to save a week's worth of dev work have realized UML isn't useful to them. Orgs that haven't don't think it goes far enough.

deleted 6y ago
[deleted]
slowmovintarget 6y ago
Let's not confuse the basic notation with the tooling and priesthood that grew up alongside it. Much like "Agile" there's still value in the small. Hashing out a class diagram that shows how the domain entities relate to each other can still be pivotal in communicating the intended information model in a design. Pre-pandemic, this would involve words, lines, and cardinalities on a whiteboard (boxes optional). Nowadays, a quick domain entity diagram in Whimsical does the trick. A sequence diagram can quickly communicate an expected interaction pattern. The point is not to specify anything up front. The point of UML was always to serve first as a communication tool. Have commonly understood pictorial notations that let you talk about the software you're building. When it was first invented, UML was aimed at "Unifying" how we diagram things. First, for books, and for the patterns movement. Even the heavy-weight Rational Unified Process was intended to be used in an iterative fashion. But it was constructed from a consulting mindset where you have intermediate steps of review and approval. Blaming UML for the heavy-handed process where "thou shalt specify everything in advance" is like blaming the English language for that crappy novel you wasted your time on. UML still has a place, IMHO, but only in that it helps you get over a few speed bumps on the way to helping your team produce working software.
- spookthesunset 6y ago
  > When it was first invented, UML was aimed at "Unifying" how we diagram things. See but “unifying how we diagram things” isn’t a problem that needs to be solved. A good diagram on a whiteboard is more art than science. It is also something that is intentionally as low of fidelity as possible because you might blow it away and do something entirely different. There doesn’t need any “standard” for how to do adhoc diagrams. The minute you add “formal standard” to the process it gets slower when you want it to be even faster. If my whiteboard diagram had to adhere to UML... I wouldn’t bother.
  - slowmovintarget 6y ago
    It actually was a problem. From the article: > In his book on Business Object Notation, Bertrand Meyer lists twenty-six competing methods. I remember reading documents that listed over fifty, but I can’t seem to find them again so it might be a false memory. I also distinctly remember how difficult it was to learn from other's designs. Back then, there was no Stack Overflow or Google. Developers like me obsessed over the latest books (like this new Design Patterns book, have you heard about it?!?) It isn't a problem today because that's not how design ideas get communicated anymore. You have blog posts, and GitHub repos with examples and Markdown. This is better. But in the mid to late 90s, UML really helped. Disclaimer: I was on many of those OMG committees for Model Driven Architecture and UML back in its heyday. I've also sat in Sushi restaurants after conference proceedings during dinner with some of the people mentioned in the article. The talk was of how we were going to change the industry. I smile to think of how things moved on without our dreams. :)
    - BlueTemplar 6y ago
      I don't see why UML diagrams wouldn't be very useful inside blog posts ?
  - Pet_Ant 6y ago
    > There doesn’t need any “standard” for how to do adhoc diagrams. Oh yes there does. I have seen people makeup ad hoc notation during an ad hoc diagram and then get confused by what it means orthe meaning shifts during the diagram. No, we have a standardised language. You wouldn't want blueprints with ad hoc units. "14 snails thick, and 3 rabbit-seconds in length which we indicate with an underlined star"
    - fargle 6y ago
      You don't need a standard for ad-hoc whiteboard diagrams or expositional figures. You're comparing apples and oranges because what you are talking about needing this level of precision in is more "blueprints", not ad-hoc diagrams. And, while it's my opinion only, blueprints for software are best written in prose. For C++ for example, I think the best language to use is concise, precise, well written, C++. And so on.
- lostcolony 6y ago
  Just to point out - you've listed two diagram types. There are 14. Of those two (which are the only two I've heard called out by their name in any business context), I've not seen consistent notation. Sometimes it's a problem, sometimes it isn't, but invariably what is more important is the conversation happening alongside the diagram; the diagram by itself is not a useful artifact, just like the slides to a (good) presentation, by themselves, are not useful.
  - slowmovintarget 6y ago
    Component diagrams, state charts, and activity diagrams also still appear in some of my whiteboard sketches. They are useful in specific contexts, but we use them far less often. The last time I drew a use case diagram, it was in jest.
    - lostcolony 6y ago
      So most if not all of UML's diagrams can show up in -some- form when conveying information. Just, no one remembers the UML, and certainly no one thinks "Ah-hah. A (diagram type) would be useful here. I shall draw one in accordance with all outlined UML conventions".
      - lazyasciiart 6y ago
        No, but when I'm drawing diagrams and realize I need to show that this relationship is different to that one, I think "Ah-hah. I will use the UML arrow notation instead of inventing something incoherent as I go".

deleted 6y ago

[deleted]

slowmovintarget 6y ago

Let's not confuse the basic notation with the tooling and priesthood that grew up alongside it. Much like "Agile" there's still value in the small. Hashing out a class diagram that shows how the domain entities relate to each other can still be pivotal in communicating the intended information model in a design. Pre-pandemic, this would involve words, lines, and cardinalities on a whiteboard (boxes optional). Nowadays, a quick domain entity diagram in Whimsical does the trick. A sequence diagram can quickly communicate an expected interaction pattern. The point is not to specify anything up front. The point of UML was always to serve first as a communication tool. Have commonly understood pictorial notations that let you talk about the software you're building. When it was first invented, UML was aimed at "Unifying" how we diagram things. First, for books, and for the patterns movement. Even the heavy-weight Rational Unified Process was intended to be used in an iterative fashion. But it was constructed from a consulting mindset where you have intermediate steps of review and approval. Blaming UML for the heavy-handed process where "thou shalt specify everything in advance" is like blaming the English language for that crappy novel you wasted your time on. UML still has a place, IMHO, but only in that it helps you get over a few speed bumps on the way to helping your team produce working software.

spookthesunset 6y ago
> When it was first invented, UML was aimed at "Unifying" how we diagram things. See but “unifying how we diagram things” isn’t a problem that needs to be solved. A good diagram on a whiteboard is more art than science. It is also something that is intentionally as low of fidelity as possible because you might blow it away and do something entirely different. There doesn’t need any “standard” for how to do adhoc diagrams. The minute you add “formal standard” to the process it gets slower when you want it to be even faster. If my whiteboard diagram had to adhere to UML... I wouldn’t bother.
- slowmovintarget 6y ago
  It actually was a problem. From the article: > In his book on Business Object Notation, Bertrand Meyer lists twenty-six competing methods. I remember reading documents that listed over fifty, but I can’t seem to find them again so it might be a false memory. I also distinctly remember how difficult it was to learn from other's designs. Back then, there was no Stack Overflow or Google. Developers like me obsessed over the latest books (like this new Design Patterns book, have you heard about it?!?) It isn't a problem today because that's not how design ideas get communicated anymore. You have blog posts, and GitHub repos with examples and Markdown. This is better. But in the mid to late 90s, UML really helped. Disclaimer: I was on many of those OMG committees for Model Driven Architecture and UML back in its heyday. I've also sat in Sushi restaurants after conference proceedings during dinner with some of the people mentioned in the article. The talk was of how we were going to change the industry. I smile to think of how things moved on without our dreams. :)
  - BlueTemplar 6y ago
    I don't see why UML diagrams wouldn't be very useful inside blog posts ?
- Pet_Ant 6y ago
  > There doesn’t need any “standard” for how to do adhoc diagrams. Oh yes there does. I have seen people makeup ad hoc notation during an ad hoc diagram and then get confused by what it means orthe meaning shifts during the diagram. No, we have a standardised language. You wouldn't want blueprints with ad hoc units. "14 snails thick, and 3 rabbit-seconds in length which we indicate with an underlined star"
  - fargle 6y ago
    You don't need a standard for ad-hoc whiteboard diagrams or expositional figures. You're comparing apples and oranges because what you are talking about needing this level of precision in is more "blueprints", not ad-hoc diagrams. And, while it's my opinion only, blueprints for software are best written in prose. For C++ for example, I think the best language to use is concise, precise, well written, C++. And so on.
lostcolony 6y ago
Just to point out - you've listed two diagram types. There are 14. Of those two (which are the only two I've heard called out by their name in any business context), I've not seen consistent notation. Sometimes it's a problem, sometimes it isn't, but invariably what is more important is the conversation happening alongside the diagram; the diagram by itself is not a useful artifact, just like the slides to a (good) presentation, by themselves, are not useful.
- slowmovintarget 6y ago
  Component diagrams, state charts, and activity diagrams also still appear in some of my whiteboard sketches. They are useful in specific contexts, but we use them far less often. The last time I drew a use case diagram, it was in jest.
  - lostcolony 6y ago
    So most if not all of UML's diagrams can show up in -some- form when conveying information. Just, no one remembers the UML, and certainly no one thinks "Ah-hah. A (diagram type) would be useful here. I shall draw one in accordance with all outlined UML conventions".
    - lazyasciiart 6y ago
      No, but when I'm drawing diagrams and realize I need to show that this relationship is different to that one, I think "Ah-hah. I will use the UML arrow notation instead of inventing something incoherent as I go".