
Ask HN: Do you still use UML? - dmitripopov
A client asks to add UML diagram support to my Helpinator, but I am not sure that it&#x27;s worth my time.
======
bane
In its entirety? No. Never go "full UML", it will annihilate productivity and
produce abominable software. It also is taught wrong, it tends to be taught as
a design tool, but there's such a tremendous impedence mismatch between the
diagramming tools and the way the code actually gets written that it ends up
doing more harm than good. (not to mention that the people who usually end up
creating the UML might be many organizational layers away from the
developers).

But there's some goodness in there. The principal of using diagramming as a
descriptive documentation and communication solution _is_ highly worthwhile,
but again it should be limited to pieces of the system that need such things.
And in addition, the level of detail should be _just_ as much as is sufficient
to communicate what's necessary -- don't "prematurely optimize" by trying to
document every bit of the system in excruciating detail.

There's also often better, simpler ways to document many aspects of a system,
a few boxes and arrows work well for many things. Lightweight versions of the
Archimate style work well for describing complete systems. Protocols are well
described by a lightweight treatment of sequence diagrams, etc.

They'll often go out of date as quickly as you make them, so keeping them up
to date and well versioned turns into a challenge.

Because it's free and provides cross platform compatibility (and the diagrams
are supposed to be communication devices), we tend to use yEd for most things.

~~~
cnahr
Indeed, I only use UML for documentation of existing code. Having a standard
allows for consistent reverse-engineering, and a class diagram is still the
best way to visualize an OOP class hierarchy.

Keeping them up to date with the code is an issue, as with all documentation.
I actually wrote my own Java class diagrammer [1] for that purpose so I can
just re-run a project file to create updated diagrams of the current code
base, with little or no editing required.

[1]
[http://kynosarges.org/Diagrammer.html](http://kynosarges.org/Diagrammer.html)

------
sly010
The 3 actually useful diagrams that I have seen in the last 10 years are:

\- Sequence

\- Entity relationship

\- State chart

All 3 are useful for communicating protocols, schemas and state charts.

Sequence diagrams are probably the most ubiquitous, and very useful in
explaining protocols. Even RFC-s have them.

Relationship diagrams are often (ab)used to visualize relationships between
tables in SQL databases. While it's not very useful for designing, I have
actually used them for understanding and simplifying a complicated database
schema. I actually believe every API documentation should start with an
abstract entity relationship diagram. Abstract in the sense that it should not
necessarily represent physical tables, but give an overview of the underlying
structure to the first time user. Doesn't even have to complete or correct.

State charts are occasionally useful for obvious reasons. Try explaining TCP
without one.

I think it's worth noting that the above 3 existed before UML and UML merely
tried to formalize them, so while I don't think anyone uses "UML" anymore,
being able to comprehend the above 3 charts is as basic of a skill as being
able to read pseudo-code, and saying they are not is use would also be false.

Edit: formatting

~~~
jackweirdy
The reward of the clarity of sequence diagrams is worth the pain and boredom
of learning all the others at university.

Sequence diagrams nicely represent separate entities involved in a system, the
order of communication between them, and the conceptual content of messages
between them. Even briefly reading a sequence diagram helps you understand how
different components relate to each other.

Often, and usually with API endpoints with some complexity behind the scenes,
I'll go out of my way to draw an ASCII sequence diagram with Monodraw[0] and
leave it in the comments or a readme.

[0] [https://monodraw.helftone.com](https://monodraw.helftone.com)

------
febeling
I use boxes-and-arrows sketches a lot. The UML which was so popular around
2000 was this detailed quasi-standard graphical language. It was very centred
around being correct, and diagrams being of a specific type of a number of
permissible types, and so on. And that whole part I never found to be too
helpful.

It is useful to draw ideas as graphics for people who's brains are wired
visually. And it can makes nice figures for books and articles explaining
structures and concepts. But in neither case does the value predominantly
depend on the depictions begin adherent to a standard, as much as other
qualities, like focusing on the right part of a larger system, or leaving out
unimportant detail, etc.

So nonstandard diagrams offer the author or user more creative flexibility,
which is often very important.

I do see value in loosely following UML notation, for the obvious reason that
one can immediately see if someone tries to show classes, states, requests,
systems parts, and so on. That was probably the original goal behind UML all
along, even if people lost sight of it during the fad phase.

~~~
agumonkey
I use to argue with a friend about this, I was so fed up with all the UML
mystique, I wanted to release CarréFleches 1.0 (french for boxes and arrows,
with the appropriate lack of grammar to mock the fluff behind UML).

Seems like everybody use the same "subset" that is graphs of things related to
each others ... what a mystery.

~~~
pbhjpbhj
OT: just realised where the word fletcher (an arrow-maker) comes from. In
French does _fleches_ refer always to the whole arrow? Just it sounds a bit
like "flight" which is the layman's English term for the feathers.

~~~
jacobolus
etymonline: fletcher (n.) "arrow-maker," early 14c. (as a surname attested
from 1203), from Old French _flechier_ "maker of arrows," from _fleche_
"arrow," which is probably from Frankish, from Proto-Germanic _•fleug-ika-_
(compare Old Low German _fliuca_ , Middle Dutch _vliecke_ ), from PIE
_•pleuk-_ "to fly," extended form of root _•pleu-_ "to flow" (see _pluvial_ ).

I think it pretty much stands for the whole arrow, but comes from the word for
“flying” back in old Germanic languages – but via the arrow being a flying
projectile, not from the feathers per se.

------
lkrubner
UML was, in some sense, an expression of a certain kind of politics:

\-------------

"And there is an explicitly political idea that drove OOP to its peak in the
1990s: the idea of outsourcing. The idea of outsourcing software development
rested on some assumptions about how software development should work, in
particular the idea of the “genius” architect, backed by an army of morons who
act as secretaries, taking dictation. OOP was the software equivalent of a
trend that became common in manufacturing during the 1980s: design should stay
in the USA while actual production should be sent to a 3rd World country.
Working with UML diagrams, writing code could be reduced to mere grunt work,
whereas the design of software could be handled by visionaries, possessed with
epic imaginations, who could specify an OO hierarchy which could then be sent
to India for a vast team to actually type out. And the teams in India (or
Vietnam, or Romania, etc) were never trusted, they were assumed to be idiots,
and so, for a moment, there was a strong market demand for a language that
treated programmers like idiots, and so the stage was set for the emergence of
Java. "

[http://www.smashcompany.com/technology/object-oriented-
progr...](http://www.smashcompany.com/technology/object-oriented-programming-
is-an-expensive-disaster-which-must-end)

~~~
kpil
I think everything you say is true except the jab at java, which is also true,
but not all the truth...

Besides, during the 90s the idea seemed to be that that the next step after
the outsourcing was actually no programmers at all. UML and 4gl systems would
handle all the complexities and laymen domain experts could just define all
bread and butter administrative systems they like - no expensive and socially
awkward nerds in the basement necessary...

~~~
csixty4
> during the 90s the idea seemed to be that that the next step after the
> outsourcing was actually no programmers at all

Lest someone think this is an exaggeration, no, this was _literally_ the
conversation at the highest levels of some companies. A relative told me to
reconsider going after a comp sci degree in 1995 because within ten years the
computers would be programming themselves. There were presentations at their
workplace about it.

My first "real" job was programming customizations hacked on top of a 4gl tool
- injecting JavaScript into pages through an improperly sanitized <label>
widget! After the whole application was rewritten in the 4gl tool, it never
lived up to its promise.

~~~
kpil
Fred Brooks where spot on in his thoughs regarding essential (as in inherent)
complexity.

I think that BPEL thankfully died just a couple of years ago, but not thanks
to some globally aquired insight but rather because a new batch of developers
isn't quite there yet so they are busy learning and reinventing basic stuff,
but now at 'internet scale'

------
smoyer
UML can be a great communication tool in specific situations but when it
becomes a religion your organization will suffer. I'm older than most here,
drank the cool-aid that predicted code generation and round tripping but spit
it back up before the poison had a chance to set in.

A bonus comment for the youngin's ... When you hear that some new system will
allow "the common man" to write his own software without developers, smile and
agree with them because they'll come back when it doesn't go as planned and
you can charge a higher rate for the resulting expedited project.

EDIT:

I should also admit that I liked (like?) the idea of writing code using
diagrams. In the '80s I wrote a program I called "Flo-Pro" in Turbo C that
never quite became self-compiling. It wasn't at all OOPsish or FP. In the '90s
I wrote several tools in Prograph [0] (now known as Marten) but was stymied by
the fact that I was the only one in the company using the tool. In the early
aughts, I tried URL tools that promised to write my code from the diagrams -
it worked for very simple code but I never saw round-tripping work.

I love drawings in general - my coworkers joke that it's not a meeting unless
I have a dry-erase marker in my hand. But those diagrams are invariably
system-level, architectural drawings. As others have noted, I also appreciate
ERD as a way to visualize relationships in RDBMS. So as much as I like the
idea, development stays in the world of text - I'm not holding my breath for
some magic bullet.

[0] [http://www.andescotia.com/](http://www.andescotia.com/)

~~~
JustSomeNobody
The youngins say AI will solve this. They're wrong.

~~~
TeMPOraL
A human-like AI will sure solve this - because the only way for "common man"
to make software without developers is to have _something_ to do the work of
dealing with complexity - figuring out the _precise_ details, handling edge
cases in a way consistent with the original intent, etc.

But why wait for a powerful AI, if you can hire / enslave developers today?

~~~
ainot
> handling edge cases in a way consistent with the original intent, etc.

That's where we spend the majority of our time and always where things go
horribly wrong in SciFi movies.

------
sidlls
HackerNews may not be the best place to sample for UML usage. It consists
mainly of two communities that have a bias against formal engineering
methodologies in the development of software.

I won't comment on the pros and cons of UML. Instead I'll invite you to ask
yourself a couple of questions.

1\. What other clients do you support who have similar characteristics as this
client (and may therefore also benefit from UML support)? If the number is
significant in terms of impact to your bottom line versus the time you'd have
to spend implementing it, then you should consider it worth your time, and
view it as an opportunity to up-sell (if you can) or keep existing customers.

2\. Do you intend to attempt to move into supporting large enterprise, and
especially government contractors? If so, you might consider UML support just
because it is ubiquitous there.

~~~
ausjke
what are the two communities are you referring to? one of them might be
frontend developers(ui,js,html,css,etc)? what is the other one?

I'm a low-level guy and learning some web coding these days, so I can tell the
difference views on software between HN and other places.

~~~
bbotond
My guess is the FP (especially Lisp) crowd.

~~~
ainot
The FP crowd is so vocal. Reformed math geeks who are trying to evangelize the
world of programming to do things one way; their way.

~~~
Slackwise
> Reformed math geeks

I presume you mean the Haskell crowd? The Lisp crowd is more about expression
rather than "correctness" and rigidity. FP doesn't really have a formal
definition.

> trying to evangelize the world of programming to do things one way; their
> way.

I think the world of computing is shifting towards a lot of async work, and if
you've ever written large threaded apps, having too much state becomes the
greatest of burdens. Clojure, for example, minimizes state and uses Software
Transactional Memory to manage mutability.

~~~
sidlls
What's old is new again, it seems.

------
EdSharkey
As a communication tool I've sold work with a really busy, boxy class diagram
where the focus is on the connections and not a complete representation of all
the properties.

Being able to stand in front of a big screen and point to and talk about
connections and cardinalities magically draws questions and comments out from
the business stakeholders. That feedback helps me get the model to a place
where it generally matches what the business wants.

Keeping that diagram alive and updated as we implement the system has served
as a super valuable tool for communication with other teams that need to touch
the model. Everyone continuously hashes out and agrees on common terms,
ownership, etc.

The worst defects come from requirements or design defects. I'm not advocating
for giant up-front designs with hundred+ page software design spec docs. But,
paraphrasing Uncle Bob, "'no up-front design' doesn't mean _no_ design." There
has to be some design of some sort and some documentation of the system being
developed.

I think the time to stop diagramming/designing is when adding more detail
won't communicate anything more about the model or business process in casual
conversations about the system. That's a very subjective line to draw, but it
helps me to think that way.

------
eksemplar
I do, quite a lot actually.

Originally it was mostly because it was the default setting in my Enterprise
Architect tool, but it's proven more useful than Archimate (and other
notations) because people without architect knowledge understands it much
better.

On the business side it's mainly the system integrations, dependencies and
information flows that are of value and you could honestly do them in Word if
you wanted. Because it's very easy to build upon it, it's also easy to turn
the business specs into something I can hand to an actual developer or use as
a common language when talking features and requirements.

I wouldn't use UML if I was doing the systems engineering from requirement
specs handed to me, and it is very rare that we use more than 10-25% of its
full functionality, but it has enourmous value when you are trying to get
future system owners to understand their own business processes and what they
actually need from their IT.

~~~
dmitripopov
Would you use UML to show BPs to a competely new user of a system?

~~~
eksemplar
I don't deal with a lot of end users, I mainly advice stakeholders and try to
make them as equipped as possible for making the right overall decisions. That
being said I wouldn't because our project maneuvers use bizagi and are
comfortable with that notation.

Given the choice I'd probably not use UML BPs a lot either. They are very good
if you want to do graphical use cases for architects, but I don't think they
have a lot of communicative value unless you know UML.

------
arethuza
I absolutely hate UML and regard the associated tools as time swallowing
abominations and the main advocates that I encountered as the worst kind of
snake oil salespeople.

Of course, other people's experience may differ - but I largely thought it was
a big con.

~~~
dmitripopov
Rational Rose was terrible at UX, but surprisingly it was a de-facto standard.

~~~
bsenftner
Now that was an expensive con. All UML bullshit is a joke: more energy is
spent on being Correct than addressing the original issue UML was meant to
solve.

------
segmondy
Yes I do. When you have a team of developers with different model of how the
system should work or works, it's usually a recipe for disaster. By modeling,
we get to unify our thoughts and idea of the system.

When starting out a project, I tend to lean more towards well labeled
conceptual diagrams. I will also use activity diagram, sequence and state
diagrams.

While I have often read about people designing class diagram before hand, then
writing or generating code. I never use class diagram before code is written.
I use class diagram to document an existing system.

It's a tool, if you are willing to be flexible and realize it for what it is,
then it's useful.

~~~
scotu
Any tool in particular that you suggest to make diagrams? Or maybe just pen
and paper?

I tried StarUML 2 and it's ok but I found it slightly clunky (it also does not
have a realtime collaboration feature as far as I know, that would be nice to
have when your team is remote IMHO)

~~~
segmondy
White board it, modeling should be a group activity. Everyone should
contribute their ideas so we can converge towards one mental model. If I'm
working with 1 or 2 developer, we can cluster around a table and use pen and
paper. I only use professional tools if I'm going to be giving presentation or
wish to store it for long term.

In Linux there is modelio, and there is also Visual Paradigm which is
available on most platforms and has a free community edition.

~~~
scotu
thanks

------
wyldfire
"What's your favorite editor?" pales in comparison to the divisiveness
inspired by "how do you feel about UML?"

I used Rational Rhapsody for a few years. We used it for use case diagrams,
sequence diagrams, class diagrams, object model diagrams, statecharts+code
generation.

Many folks scoff at and draw the line at code generation. By default, tools
like Rhapsody seek to box you in to a certain way of doing things. It's not
difficult at all to customize but it requires effort to opt out of some
defaults. I felt like I experienced significant pros and cons. One one hand it
was awkward to use their IDE to edit the code. OTOH it helped encourage a
level of organization to the code. Statecharts are very expressive and very
clear, I really liked them. There's no limit to the expressiveness of the code
you can write. But the vocabulary used to describe the widgets I was working
with was new to me, so it took a good deal of time to look up and understand
the customizations required.

In the absence of code generation features of UML, the diagramming features
are really great. Developers are too quick to treat it like a religion and (on
both sides) become inspired to pray at the altar or preach about the evil that
lies within. But really, it's just a glossary of visual representations mapped
to software design concepts. That's all it needs to be -- conventions like the
ones used in other engineering discipline's diagrams. Diagrams with "boxes and
arrows" are just fine but there's always the implicit questions: "does that
rectangle represent the process executing the 'flabtisticator executable' or
the 'flabtisticator class'?

------
mannykannot
Back in the late 80's, there was the CASE (Computer-Aided Software
Engineering) fad, when it was thought diagrams could replace code.

The idea that a picture is worth a thousand words is not applicable to most of
the words one would use to discuss systems designs. It is very difficult to
discuss purpose and intent, or to present arguments that the design satisfies
requirements or observes constraints, to justify choices, and say how things
work, through any sort of diagram, let alone only those of UML (use cases are
something of an exception, as they are not actually diagrams.)

On the other hand, diagrams are a very useful adjunct to these activities, and
are widely used in informal discussions. This is broadly in line with how
diagrams and pictures are used in other technical and scholarly fields: for
example, maps, statistical charts and pictures of places and artifacts are
very useful in history articles, but are never the full story.

Furthermore, I can usually write a thousand words faster than I can draw the
corresponding UML diagram. The UML I am most likely to use will be machine-
generated from code and will be used as a supplement to the text I am writing.

~~~
k__
When going into a new OOP project, I like to browse the code and create class
diagrams for it.

It's intersting to see what classes aren't used at all and where all the
associations accumulate.

Also, if the "previous devs" are still around it's easier to talk with them
about these pictures, than to talk about 100 text files.

~~~
mannykannot
Good point. I find sequence diagrams can be useful in places, as well.

------
elsurudo
UML is too heavy and rigid.

I use my own subset/version of UML, which uses a simplified "grammar", and
allows you to express basically only the following:

\- Class with attributes \- Parent/child relationship \- One-to-one
relationship \- One-to-many relationship \- Many-to-many relationship

If I have some other need (rare), then I improvise. Usually I'm the only one
who looks at these, but if a client or someone else needs to, the language is
simple enough to understand that I can explain it in a few examples/sentences.

~~~
CyberFonic
An ERD (Entity Relationship Diagram) might be simpler and clearer. In my
experiences, stakeholders find them easier to follow than UML class diagrams.

~~~
collyw
For me its also a lot more useful to document he data model rather than class
diagrams. The data model usually changes less than the code.

------
cageface
Not exactly UML but I find rails-erd can be helpful to understand a data
model, particularly if I'm trying to come up to speed on an existing codebase.
It has the very large benefit of automatically staying in sync with the code.

[https://github.com/voormedia/rails-erd](https://github.com/voormedia/rails-
erd)

------
mark_l_watson
I co-wrote a book on UML years ago. Back then, I thought that UML diagrams
helped with communication. However, Sequence Diagrams are the only type of
diagrams I use anymore.

For Java, perhaps high level class diagrams are still useful also, but I have
been switching over to using Haskell (as much as I can) and I have not worked
on a large Java project in a long while.

------
kaio
Yes, but not in the formal sense. And i don't get why agile and proper
documentation should not go Hand in Hand. There are components and class
Diagramms that are invaluable for me when i'm joining an existing code base.
Even if they are not up-to-date everytime.

State and sequence diagrams are really cool to discuss dynamic flows and
identify potential logic holes. UML-like diagrams are way better then to come
up with your own representation of this everytime

~~~
dmitripopov
Time limits, I guess. It's the only reason not to create good documentation.
If you fail to deliver on time there's no need in good project docs. More like
a chronic desease.

~~~
taylodl
A lack of good project documentation should be treated as technical debt and
handled accordingly

------
maxxxxx
For a while I used UML but whenever I showed them to even experienced
developers they didn't understand them. So I went back to simple box and
arrows. Easier to understand and also easier to create and modify. Flow charts
and state machine diagram usually work too.

I almost have a prejudice against people who use UML because a lot of them
seem to be the "architect" types who talk about integration patterns and stuff
but don't get much done.

------
the_mitsuhiko
I don't think i ever did. It feels like an enormous waste of time.

------
lpasselin
I am on a 5 min break of working on a school project where lots of UML
diagrams are required. I was finishing our last required sequence diagrams
right now!

Although this is a small team project, making the diagram takes at least 5
times the time needed to write the code. In our team of 4, 3 of us will not
need to write code.

I understand it is good for management but I hope I will never be required to
do this ever again.

------
llndr
Sequence and state diagrams are fine, why not using them when you want to
communicate certain things?

~~~
dmitripopov
I notice that young coders hate to deal with diagrams. Customers are more and
more educated in IT, so in most cases there's no need for intermediate
language to communicate.

------
Svan
I do. UML class diagrams can help you turn real world business objects into
model and think about dependencies and relationships of entities. I would say
that it is the best tool to model software. Sequence and activity diagrams can
help you design and document a process.

A picture is sometimes worth hundred words and this applies to UML as well.

~~~
dmitripopov
Sure, pictures are great for communication. But is UML required? A lot of
teams that I observe go with arrows and boxes on a whiteboard, and everything
is clear nonetheless.

------
lisper
IMO UML adds negative value because, with only a very few exceptions, its
semantics are carried by shapes that have no mnemonic relation to the concepts
they are intended to communicate. What is the difference between a dashed line
and a thin vertical box in a sequence diagram? A hollow vs a filled diamond in
a class diagram? Does:

C1 ---> C2

mean that C1 inherits from C2 or that C2 inherits from C1? Does:

C1 ---* C2

[Note: the * is supposed to be a filled-in black diamond, but HN apparently
doesn't allow unicode characters in comments.]

mean that C1 contains instances of C2 or that C2 contains instances of C1?
What would it mean if the diamond were hollow instead of filled? What is the
difference between a solid and a dashed line in a class diagram? A sequence
diagram?

The only way you can possibly know the answers to these questions is if you
have mastered an enormous amount of trivia. And then what have you actually
gained? How is a class diagram better than simply writing out as text, "Class
C1 inherits from C2, C3 and C4, and contains single instances of C6, C6 a set
of C7s, and an ordered list of C8s?"

In >90% of cases, the information conveyed by UML can be much more easily and
effectively communicated by plain text.

~~~
dpark
> _How is a class diagram better than simply writing out as text, "Class C1
> inherits from C2, C3 and C4, and contains single instances of C6, C6 a set
> of C7s, and an ordered list of C8s?"_

I agree with much of your criticism of UML, but there is significant value in
having a visual representation of class interactions. Your text takes longer
to parse and understand than a simple diagram would be. For scenarios with
numerous classes, the diagram becomes _far_ easier than a text description.

~~~
lisper
> the diagram becomes far easier than a text description

If the text is hyperlinked it can be every bit as easy to follow as a diagram.
In fact, it can be easier if things are really complicated because it allows
you to focus your attention more easily just on the parts that matter to you
at any given time.

~~~
dpark
I don't agree with this at all. People naturally draw diagrams to demonstrate
complex things. Any time a technical discussion gets complex, someone walks to
a whiteboard or pulls out a piece of paper and starts drawing flows or
interactions or whatever to clarify the discussion. Never have I seen someone
say, "this is getting hard to follow, let me write some prose".

If class diagrams are useless then so are bar graphs and scatter plots. You
can just list out the data points and everyone can read them.

~~~
lisper
No, graphs and scatter plots are useful because the spatial distribution of
markings actually conveys useful information: things that are physically close
to each other are mathematically close to each other. But most UML diagrams
aren't like that. And even for the ones that _do_ try to convey information
that has spatial analogs (like containment) UML doesn't actually take
advantage of spatial relationships between elements. For example, the natural
way to express containment is by putting one element inside the other in the
diagram. That makes it obvious what contains what. But that's not how UML does
it.

Just about the only diagram that has a natural mapping from spatial
relationships of the diagram elements to the actual underlying semantics is
the sequence diagram.

~~~
dpark
"Spatial" isn't particularly meaningful when talking about classes, so it's
not surprising that UML doesn't generally attempt to express that.

We can probably just agree to disagree here. I think class diagrams are often
quite useful. They existed before UML and they are used even by people who
don't use UML.

~~~
lisper
> We can probably just agree to disagree here

That works for me :-)

------
bunderbunder
For general purpose data modeling, I tend to favor some loose variant of
Bachman or Chen notation. UML feels complicated to the point of being hard to
read.

For architectural diagrams, I just use basic boxes, arrows, cans, etc. UML
also tends to feel complicated to the point of being hard to read.

In both of the above cases, I think my not using UML is because its goals
differ from mine. UML seeks to capture how a system comes together as
completely an accurately as possible. I tend to think that the code should
suffice for that (and if it doesn't, it's time to have a long hard talk about
technical debt). I prefer diagrams to just be a gloss that helps to explain
how things come together at a high level.

For understanding protocols and suchlike, though, UML sequence diagrams are my
go-to. That's a rare spot where I really do want the diagram to capture a
whole lot of fine detail, and the UML standard provides a pretty clear,
intuitive and uncluttered visual language for the job.

------
stevesun21
Yes. It is the language designed for software engineers to share designs,
logic and ideas with others. I never enjoy the scene that two engineers talk
designs in front a white board by keep writing some random words they catched
during talk and draw some wired line and cycles. The most painful part is that
even they take a picture of it, they still have to argue about the ideas later
when they start coding. :-(

UML is actually the first language a software developer should learn. The most
ridiculous words I have heard is that a senior engineer "mentor" other juniors
say the IBM Rose is UML! And argue about how Rose huge and hard to use.

I really worry if there still have some deciplines exist in software industry,
if so many people still obsessed to call themself software engineer?

------
pjmlp
Yes, all the time.

We don't go full UML, but it is the best tool to have a solid architecture
overview, before committing to solutions that won't fit with what customers
actually want.

It is also a very good tool to onboard new developers into the team without
forcing them spending endless hours reading code.

------
qznc
I'm teaching it. It feels increasingly out of date. Tool support has stagnated
for years on Linux. Modern features like lambdas are not really supported.

~~~
zAy0LfpBZLC8mAC
> Modern features like lambdas

"Modern" as in "Introduced to programming languages 35 years before the
invention of UML, finally turning up in Java 20 years after the invention of
UML"?

~~~
qznc
Yes. Why did the functional programming people need so long to convince the
rest of the benefits?

~~~
zAy0LfpBZLC8mAC
For the same reason that it always takes conservative people long to
understand the benefits of what they are fighting against?

------
larve
I do quite a lot. I use it for sketching out and documenting software. I use
state machines for, well, state machines, which make up 90% of the software I
write (embedded). They can almost mechanically be transformed to sourcecode,
but I do the coding by hand. I use it for sequence diagram to sketch out and
document sequences of events, and also generate sequence diagrams out of trace
logs. And finally I use class diagrams to document the software architecture.
For all of these I use plantuml because the text format is simple, human
readable, and easily versioned. For the kind of software I write (embedded
software with a lot of state machines and strong OO architecture), it is
absolutely great. Definitely one of the big tools in my toolbox.

------
cs02rm0
I don't and if you're religious about it, I'm afraid I don't want to work with
you (I accept the feeling may be mutual)!

Most developers don't have a complete knowledge of it and don't enjoy writing
it; essentially I believe it's because they know it's not an efficient way of
communicating ideas with other developers.

Modelling can be useful, but as far as I can work out something like gliffy
with lines, boxes and little else is almost always sufficient. I'd imagine
safety critical space or aviation systems and other niches are a different
kettle of fish.

------
jakub_g
Been working in a large corp for last 5 years. Never created a single UML
chart, maybe I've seen one or two.

Maybe it's because I work in front-end, which "traditionally" is a bit less
strict (JS is dynamically typed etc.), but also, I think that typically the
codebase changes too rapidly and the fancy graphs can't catch up with that,
they get outdated in a few months, and no one bothers to update them or even
look at them anymore (they might be useful in the beginning of the project
though).

------
BjoernKW
Yes. Keep in mind though that the - perhaps historically, perhaps still - most
widely used kind of UML diagram - the class diagram - is just one component of
UML.

Other than for explaining particular design patterns I don't find class
diagrams all that useful, certainly not for giving you a complete picture of a
system that consists of more than a handful of classes.

Sequence diagrams, state diagrams, use case diagrams, basically anything that
involves or describes activities: I think those are tremendously useful.

------
alemhnan
It is useful if you are able to generate code from it. I know one big software
company (more than 3000 employee) that generate 90% of all it's code base
(~20M lines of code).

~~~
charlesdm
I bet they sell quality software..

~~~
JustSomeNobody
No way of knowing unless we can exam it. Could be the best stuff ever.

------
altharaz
Good UML diagrams are hard to write, easy to understand.

I used to write a lot of UML diagrams in Mechatronics Engineering for a big
company, where specs were not supposed to change often. For projects with a
long lifetime and a slow change velocity, UML is totally justified.

UML diagrams are not worth it for Software Engineering: code evolve too fast
to keep your diagrams up to date. In that case, I replace UML diagrams by
simple sketchs / mockups and simple tables.

~~~
dmitripopov
Even bad UML diagrams are hard to write for a human that is more into typing
than drawing. I was even forced to create text-to-UML tool when I was a young
dev. Saved a lot of time.

------
krschultz
I'm an extremely visual person so for me diagrams are incredibly useful. I'm
constantly drawing class diagrams and communicating via pictures. I want UML
to work so bad.

Unfortunately, I think UML suffers from all the dysfunctions of a language
designed by many stakeholders. It's just not intuitive, so you have to
remember the details. I start practically every handwaivy whiteboarding
session with the disclosure "this is not UML but ...".

As with many "standards", we've sucked the oxygen out of the room by saying
this is the one true way. I very much prefer having multiple competing
specifications and letting the winner shake out. I imagine if we hadn't
prematurely standardized on UML years ago, visual programming and diagramming
would have evolved in exactly the same way regular programming languages have
evolved. Why do I have 30+ choices for what to write my web server in, but
only 1 seriously spec'ed out language for drawing it?

------
Blatorg
I would say it really depends... There are UML diagram generators with whcih
you might want to integrate (e.g., PlantUML) that would meet the needs of
someone creating documentation. Alternately, they may use their own UML tool
(or a free one like Eclipse Papyrus) to create the diagrams they need and then
extract those as pictures that you can import.

IMHO, adding full UML support is crazy for your application and would
potentially add years of development.

Even adding simple, non-model based UML creation would be a significant burden
if you are a small company. Plus, there might be open source generators or
generators you could call programatically to generate the images desired.

But first, you probably need to better understand your client's actual needs.
I have doubts that they would need all the UML diagrams...

------
sheraz
Nope. Whiteboards and maybe a photo of it for posterity :-)

------
brunosaboia
As almost in any case with computer science, the answer is "depends".

UML diagrams can be very useful to represent a system to someone which is not
technical enough to understand code, but can understand the basics of the
diagrams.

Personally, to myself it's usually more a waste of my time.

------
xtiansimon
UML was useful for visually communicating document architectures in the Web
1.0 world. But what's a UML diagram for a dynamic web application?
Server<\-->Database, done? If the tool doesn't fit the problem, don't use it.

And then there's the domain specific UMLs, such as Operations Management and
BPMN, where the diagram can be programmatically "powered up" to analyze
operational efficiency. If you work in a hierarchical organization where you
need deliverables that filter to other departments, and there is a perceived
value, then someone is going to be tasked to make it. But in a flat
organization in startup mode, it's a waste of money.

If you're working across organizations, in public/private partnerships; if
your government organization needs to be accountable at diverse levels, then
UML is visual language that communicates a lot of information at once--in one
artifact. Tax dollars going for new transportation infrastructure in New York
City, maybe there's a need to get diverse groups on board. But you're going to
pave potholes in Levittown, NY--who cares? Get it done; stop wasting money.

And finally, there is a the language-cultural dimension. Europe is multi-
lingual, so it's no surprise the Open-Education Resources offering UML-like
education materials are from European universities [1][2], and not American
Universities. That's not our language problem (yet).

If you have a customer asking for UML, you need to understand their problems.
Once you do that, then you can decide if the problem vector they present is
profitable sector for your company.

To put all this in other words, UML is a tool and a visual language. Use it or
not, it's not going away--ever.

[1]:
[https://open.hpi.de/courses/bpm2016](https://open.hpi.de/courses/bpm2016)

[2]: [https://www.edx.org/course/creative-problem-solving-
decision...](https://www.edx.org/course/creative-problem-solving-decision-
making-delftx-tpm1x-0)

------
cmrdporcupine
UML use case, activity, and sequence diagrams are perhaps quite useful. I'm
too lazy to make them :-) but I find them useful to consult at times.

The class diagrams that everyone is really thinking about when they say "UML"
are imho kind of useless. It reflects a kind of obsessive OO purism, and
taxonomical obsession, that was quite trendy in the late 90s, early 2000s.

But it turns out in most cases looking at a class diagram doesn't really tell
you much about what software _does_ or how it _works_. And in any case I
personally find it easier to look at header files or source files to get a
picture of how things fit together. Class diagrams don't really help.

------
xjay
#Related

There was a recent talk about the model-code gap [1]. How diagrams often don't
map to the code. The C4 model. "Structurizr." Lack of common abstractions to
describe software, in contrast with other fields like electrical engineering.
Good to still start out with paper/whiteboard.

@7:13 "1 out of 10 people use UML," in his experience. People adopt ad hoc
notations instead.

His use of UML is not for describing the system at a high level.

[1] GOTO 2016 • Visualise, Document and Explore Your Software Architechture •
Simon Brown

[https://www.youtube.com/watch?v=GM_J_jRp62g](https://www.youtube.com/watch?v=GM_J_jRp62g)

~~~
codemac
The best way to make sure your diagrams map to code, is to generate your
diagrams and the code from a common piece of text.

At a job not too long ago, we used a modified form of DOT to describe a
protocol state machine. This generated dot, .h's, and some template .c files.
This made it such that each state machine for the protocol had a diagram that
would map out all the states. Logging and other subsystems output were
generated as well so you could go from a log of a test run back to a diagram
of what had run.

Code generation (or compilers for compilers) are entirely underrated outside
of Lisp, and they're not too difficult to create.

EDIT: And note that your linked presentation is AWESOME, but I think he misses
the description / guidebook being up to date is best accomplished by having it
be what needs to be updated to create the software.

------
mikekchar
I draw UML diagrams frequently. I almost never persist them, though. As they
say, the only thing worse than no documentation is out of date documentation.

I can definitely see an argument for certain types of projects (libraries and
frameworks). If you have diagramming capability, and you are in the enterprise
Windows market, I think this is a no-brainer. I'd be curious what diagramming
support you had if it were not UML....

Having said that, I wouldn't try to implement a full object modelling
solution. It's not the kind of thing that help files need. Actor diagrams and
sequence diagrams would make more sense to me.

------
slim
Yes. Everyday. With a pencil on a notebook.

When I take notes, some concepts are better/faster materialized as
relationships between objects or actors or activities

Also reasoning about schematics topology is useful and enlightening when a
problem is large

~~~
slim
Btw when I need to sketch uml on a computer I use violet uml

------
wangchow
I have used mostly the class diagrams and sequence diagrams.

I like how UML class diagrams defines the different potential relations
between objects involved in software.

It would be nice if more people (myself included) learned better ways to
consistently communicate software design. Lots of ad-hoc meetings result in
confusion because often a design is scribbled in ones own notation then
communication takes longer. But yet such communication is crucial to large
projects.

Some call it architecture, others call it design patterns. Either way its
important to have thought-out, standard ways to communicate ideas.

------
moss
I'll often use sequence diagrams or entity relationship diagrams when I need
to explain how a piece of code works (or even just visualize it for myself). I
don't tend to be very pedantically correct about it, but having a picture
makes it a lot easier to follow how different pieces fit together. I generally
leave out a lot of the less important details when doing this.

I wouldn't generally use it to design code that hadn't been written yet.
There's a lot you only discover once you get something working, and that needs
to inform the design.

------
double_entendre
I haven't found a better activity diagramming tool than PlantUML with Vim's
aklt/plantuml-syntax and using watch to automatically build the diagrams.

I challenge any of you to come up with something better.

------
Raed667
I only ever used it for school projects, and only because it was required.

~~~
dmitripopov
Some 10 years ago I took part in two very large projects in two different
organizations, and in both cases all our shiny diagrams were scrapped at the
end. So sad :)

~~~
Raed667
For school projects, we did all the code, and then generated UML
accordingly...

All teachers knew that, but let it go

------
meekins
I'm really lazy when it comes to maintaining docs and mainaining UML is
sometimes a pain so I only use dynamic parts of UML like sequence diagrams on
a relatively generic level that is less likely to change (examples of call
flow between modules/tiers with different responsibilities).

Class diagrams are pretty nice when building a rich domain model since it's
pretty easy to move from rough conceptual level closer to designing and
documenting the actual implementation while working on the same diagram over
time.

------
edem
I sometimes create UML diagrams but I try to simplify them as much as
possible. Sequence and Entity relationship diagrams are useful but the rest is
rubbish IMHO. I tend to use them only when I'm in the planning phase but I
ditch them when they become obsolete and the application is ready. This might
not be the best workflow but updating diagrams is horrible. You also can't
really use UML for functional languages like Clojure. I feel that they are
becoming more obsolete with each passing year.

------
Achshar
I never got into it to begin with. But I did ended up using a form of few
diagrams that I later learned were part of UML. They just come to anyone who's
solving a problem naturally.

------
gaius
I'd rather use XML than UML and that's saying something.

------
partycoder
UML diagrams are practical, but there's a cost to creating them and
maintaining them. You can argue that many tools have been created to address
this problem, but the problem remains... especially maintaining them.

Now, sequence diagrams remain one of the best ways of explaining distributed
workflows (e.g: OAuth) that I know of. If you work with an OOP language, a
class diagram might be useful to express some ideas. Other UML diagrams are
less used.

------
_nalply
I still think in use cases but without the goofy graphics. I just make a
Markdown bulleted list then give the use cases each a name and a short
description.

~~~
dmitripopov
Old habits die hard :) I always start a new project with actors and use cases,
but without any diagrams.

------
flurdy
No, and yes. I, and my last few places I worked all use sequence diagrams,
especially when dealing with a new feature with a microservices based
architecture (private and gov clients). But very basic usage. I do spend a lot
of time tinkering with diagrams in
[http://www.websequencediagrams.com](http://www.websequencediagrams.com) both
for work and hobby projects.

------
jschwartzi
I use sequence and communication diagrams, but I find the other diagramming
techniques less applicable to the type of work I do. In the systems I work
with most problems arise from transitions between states and from
communication issues between isolated units. I find that static models just
end up having to change rapidly throughout the implementation, so I focus on
creating APIs and tests instead.

------
mhd
In recent times, about on the same level as ERDs for databases. So mostly as a
quick top-level sketch when designing something (mostly on paper), not really
kept up to date when the code/model changes. Goes along with getting away from
rigid class models in general, and for UI classes, the relationships are a bit
more self-evident.

I do miss Booch's fluffy clouds a bit, though.

~~~
CyberFonic
Even Grady Booch thinks that UML is not so useful.

------
euske
UML (as ERD) is used by the official IT certification in Japan. So yes, some
of us still have to learn it.

cf.
[https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2...](https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2016h28_1/2016h28h_db_am2_qs.pdf)

------
cordite
The only concept of UML I use is the N-many relationships, adding a number or
asterisk to the edges between things.

------
mugsie
Yes - mainly for communicating with other teams. Its not the full spec, but a
sub section, so that others (mainly the security architecture review) can
understand the basic parts of the system.

I tried to keep it up to date for the public docs, but that can be an uphill
battle.

------
coldcode
I don't use UML, nor its predecessors going back to the early 1980's. I draw
little pictures to ensure I understand what my code is/will do but that's it.
Formal diagrams are as useful as formal documentation written wearing a formal
suit.

------
sfaruque
If I must use UML, I prefer using Yuml ([http://yuml.me](http://yuml.me)) to
generate them.

Easy to use, allows you to "code" the UML structure in a simple template
language, and the output looks rather nice.

------
Torn
Sometimes, in google drawings to talk about code or systems architecture in
the abstract

~~~
dmitripopov
Is it general coders talk or project-related? Do you use it to communicate
with clients?

------
dirkdk
Sometimes I like to use class diagrams for my models and sequence diagrams for
API calls. State diagrams.

But just for higher concept sketching and most definitely not for generating
code. I tried that, 12 years ago with Rational Rose. Boy did it suck.

------
prav
Yes, used the UML class diagrams, sequence diagrams and Statechart diagrams
for an embedded device software.

It's just a tool for modelling. You can pick and choose the diagrams you need,
and at the abstraction level you desire.

~~~
ausjke
which uml tool you use? tried umbrello and argouml but not very impressed.

~~~
prav
We used Enterprise Architect.

------
kyled
Usually I diagram the very high level architecture of the program. Anything
lower is to volatile and wouldn't reflect the design due to code changing all
the time.

------
steedsofwar
In the last 16 years (i've worked at over 10 companies) i've only had one
company use UML and it was only for an overview of the proposed architecture.

~~~
double_entendre
And is there a better tool for displaying "an overview of the proposed
architecture"?

------
wayn3
never did. whats the point?

~~~
akytt
Communication. You get a shared language between people in hopes that when you
draw a box it could mean the same thing to people in different orgs and
cultures. Can't really design anything large without communication.

------
ainot
ERD's and Sequence Diagrams are helpful on occasion, that's it though. And
those can be done in any drawing tool.

------
mattmanser
No, nor have I seen any diagrams or had it mentioned to me by any other
programmer for at least 5 years.

------
je42
plantuml is nice. ;)

~~~
IshKebab
It is, but mainly for sequence diagrams, flow charts and state diagrams. I
think OP is asking more about object/class diagrams which I've never seen much
value in.

~~~
double_entendre
There's no evidence to think that at all. He's talking about diagramming for
helpinator, which could very well include sequence diagrams, flow charts and
state diagrams.

Biased a little?

------
staticelf
No, I have always hated it. I rather be flipping burgers at McDonalds than use
UML.

------
burnt1ce
I like to draw UML every so often.

Question to HN: What tools do you guys use to draw UML diagrams?

~~~
yoz-y
planUML changed my view on UML. The basic application is extremely ugly and
the output is far from being good looking, but writing UML in plain text is
extremely refreshing.

~~~
double_entendre
You mean PlantUML?

~~~
yoz-y
Oh, yes indeed!

------
kabes
UML seemed to be tailored for java. I stopped using it when i stopped using
java

------
maplechori
requirements in any real life scenario change every day, useless

~~~
dmitripopov
I guess that is the reason why UML failed. Documentation updates took more
time than coding.

------
qwertyuiop924
never have, never will.

------
probinso
I use it in interviews. That is about it.

~~~
bbcbasic
Aye those rites of passage

------
NoCanDo
No. Not worth it.

------
myf01d
It's just big corporations bullshit to fill meetings time.

------
douche
Probably it is not. I think I'm late enough that I missed the UML wave, and I
also did well enough on the AP CS test that I tested out of the CS 101 Java
course in college, and got thrown into the Haskell one instead, so I was never
forced to do UML.

Once in a while I'll fire up Visio and sketch out a state machine or sequence
diagram, but all I'm really doing is throwing down some bubbles or rectangles,
drawing some arrows between them, and tacking on some labels. It's nowhere
near as formalized as UML, but it works well enough.

