Comment by another2another | Hacker News Reader

Comment by another2another | Hacker News Reader

Parent Full thread

another2another

A lot of harsh words for UML, and it's not something I use myself much anymore.

But... I have used it for a few projects where I was starting from scratch, and I have to say they were some of the best and easiest projects I've ever delivered.

The act of designing the components, objects and interactions allowed me the time to think out many design problems and unanticipated interactions between the various elements and other systems I was interfacing with. Listing and adding the requirements of each stakeholder made my solution more complete and rounded for version 1.0. And since the design actually followed the implementation fairly closely (a rarity I know), it was one of the smoothest development experiences; and I had some fairly good documentation already produced that allowed me to explain to others how the system worked, and that gave them a step up when supporting it, or adding new features.

Also, since I'd spent the time doing some use cases and talking them through with stakeholders, the non-technical users and testers already had a good grasp of what was being built and how to test.

This was a fairly modest amount of UML documentation that I produced, as I see no value in designing every little detail up front, but that act of designing and thinking through the issues made these projects some of my smoothest deliveries ever. And to this day I've not seen a better successor to UML for picking out and describing bits of your solution. It sure beats the usual rush-to-code and iterate until it approximates that very often happens.

> The act of designing the components, objects and interactions allowed me the time to think out many design problems and unanticipated interactions

Sure. But you can do all that without UML. Text is perfectly adequate technology for planning ahead.

Well, I can pick up a piece of paper with classes, or a sequence diagram and external systems, and then tell the story from many perspectives to another person.

"This depends on that, this calls that, and then calls that external system via this interface..." and so on.

With a only text I would find that much harder to communicate. That's why I find diagrams much better - you can just jump in at any point and explain things in any order you like, usually with the aid of a pointing finger :-)

> With a only text I would find that much harder to communicate.

And yet you just did it:

"This depends on that, this calls that, and then calls that external system via this interface..."

I really don't see the salient difference between

    this depends on that

and

    this <-- that

(Or is it this --> that? Or this --<> that? this --<>* that? I can never remember.)

In my experience, the difference comes when you have many relationships which are organized into higher order relationships (eg, subsystems).

English is linear in a way diagrams are not.

"Text" != "English". Text in general need not be linear, e.g.:

    System1
      sub-system1a
      sub-system1b
    System2
      sub-system2a
      sub-system2b

(This is the reason indentation in programming languages is a thing.)

But trees are trivially linarizable. What will you do when you need to describe a graph, when there's some direct relationships between sub-systems?

(Yes most programming languages use trees, it has some advantages. But most people program in excel anyway.)

> But trees are trivially linarizable. What will you do when you need to describe a graph, when there's some direct relationships between sub-systems?

Graphs are reducible to lists of nodes and edges which are very linearizable.

That may not be the most useful form for comprehension, but linear forms are quite good for writing and storing. Visual notation is useful for presentation here, but IME quality is much lower in drawn diagrams than rendered-from-linearly-authored-text diagrams, which explains why most of my diagramming is done in a text editor (e.g., in Markdown+Mermaid) with visual preview.

> What will you do when you need to describe a graph

What will you do when you need to describe a graph with (say) more than a thousand nodes? I hope you won't try to draw a picture of it.

Why not? Feeding it to graphviz is one of the viable avenues of attack.

And what exactly is the "it" that you "feed to graphviz"?

Creating a graphical rendering of data is not what I was referring to when I spoke of drawing a picture. What I meant was actually drawing, i.e. using MacDraw or PowerPoint or a pencil and paper and drawing. Because that is what people mostly do when they use UML.

Electrical circuits were mentioned and yes they are usually designed by drawing AFAIK, even with over 1000 nodes. What's the argument here?

> they are usually designed by drawing AFAIK

I work at Intel, so I can tell you with some authority that you are mistaken.

This is not a pure defense of UML, but text is not perfectly adequate. Visualizations do wonders for understanding that text can’t touch.

This is why PlantUML is great. It is both text and a visualization.

https://plantuml.com/

The problem with text is that it takes a lot of writing to describe complex interactions and the reader checks out somewhere in the first quarter of your prose.

Diagrams are more efficient to drive the point home.

Readers check out with those, too. I've found that's largely because everyone has a slightly different perspective on what something means, ergo everyone's always talking slightly past everyone else and the discussion doesn't amount to anything. It takes a very skilled learner to say "I'm shelving my idea so I can understand yours." And it takes a very skilled teacher to simulate a learner's brain with their own. Diagrams don't solve this problem, in fact, no tool does.

Text is okay, but describing a graph is difficult and not as intuitive as a diagram. This doesn't mean UML is needed for the diagram, however the alternative is a semantically weak ad hoc diagram, and I'm not a fan of UML even though have plenty of experience, I agree that UML basically had good intentions for a real problem, poorly executed.

and yet grafviz does it just fine.

netlists do a perfectly fine job of describing graphs

I think there is a distinction between UML as per the 1000-page spec vs drawing some class diagrams with lines in-between that makes sense to you. Visual representations are very useful, as most of us are orders of magnitude better/faster with images than with text. I also like to scratch in the planning phase something that might resemble UML from far, but I think that is strictly different from it.

You mean that the projects that you knew well enough to design before starting were easier than the ones you didn't?

Reply on news.ycombinator.com