For solo projects, no. I use pen and paper to work out algorithms, but I don't use diagrams. I feel like they are slowing me down.

For team projects - that kind of depend on the kind of people you've hired/are leading. If you have inexperienced developers that can't design good API, it is a good idea to design the overall API by yourself and let the juniors implement it. In order to communicate better, class/sequence diagrams plus some free-form drawings that describe this or that design pattern. With time and experience, however, the need for these diagrams disappears. Plus, there are tools to automatically generate some of the diagrams, so I see no sense in doing them yourself when introducing someone new in the team.

One use of UML-like diagrams that almost always comes up is during the design process in my team is when designing a database schema. However, they are never maintained, as once you do the database, you can automatically generate a graphical representation.

If people that show strong dislike for UML... I'd say there are even more weird stuff happening in academia (e.g. ADLs, architecture description languages). Their problem is that they never work in big teams, never work on big projects, never support anything they write and very rarely get the chance to test their ideas in the real world.

Virtually everyone I've ever worked with has used an informal "pseudo" UML when explaining relatively complicated systems. Nobody uses it completely, but frankenstein UML diagrams are still a good communication tool. The main problem with UML is just that it's way too complicated in its complete form.

I love so many of the responses in the thread:

I don't use it. It is awful ... except I'll use it to make "back of the napkin" notes, and when talking to others about designs.
I don't use it. ... except to document the flow between processes, then I might use a communications diagram.
I never use it... but I have tools that generate it that I use to talk about systems.
We don't use it ... except we build diagrams by hand before the system is built, then use auto-generated diagrams.


You may not use UML (or your own interpretation of boxes and arrows and flows) on a daily basis, but when it comes to communication and planning, it is a valuable tool. Noted above, even most of those people who said they don't use it went on to describe cases where they did.

You may not use UML (or your own interpretation of boxes and arrows and flows) on a daily basis, but when it comes to communication and planning, it is a valuable tool. Noted above, even most of those people who said they don't use it went on to describe cases where they did.

"UML" is not a synonym for "anything that vaguely resembles a diagram." UML is a very strict specification for making diagrams. I do NOT use UML as I do not follow the spec in any sense of the word. I do however use diagrams to communicate.

Please don't conflate diagrams for communication with UML.

I really hate to argue about it, but you might want to re-read the thread title and the original post.

Specifically, "use UML or other diagrams".

Most of the posts are mentioning the "other diagrams" aspect.

It is a bit frustrating to see people who ought to know better (or who ought to read more carefully) derail the question on UML as code generation being evil, or the stricter formal UML definitions, when this is primarily about "or other diagrams" being useful to an individual. While there is a formal UML specification, the concepts and markups used in UML have spread to most modeling tools. You may not be using the formal versions, but instead use the concepts from it. But those are not what the original question was about, reread it.

You may not use the stricter formal UML requirements, but you repeatedly state that you use other diagrams. Which seems to make your answer a resounding "YES!"

I've seen UML and other similar diagrams used at every office I've ever worked. I've seen it in the vast majority of modern technical books covering systems-level designs and architectural patterns (as opposed to finer-grained book on specific languages and those details). They are an excellent way to communicate, even if you are communicating from your past self to your future self.