What diagrams do you use in software development?

I use drawio, as those diagrams are quite future proof (drawio is open source, very old and you can embed diagrams in svg files) but also very expressive (you can even use latex inside drawio diagrams).

Since I created a drawio integration extension for VS Code, I tend to create much more diagrams during coding, as they are really cheap to create. There is also an extension for IntelliJ and the diagrams work nicely in github readme files. After moving diagrams closer to code, I noticed that it is much easier to keep them in sync with the code base. Especially as PRs changing the code structure can include diagram changes at the same time.

I use them to model simplified class diagrams for documentation purposes, to model data flows, to create primitive mockups, to show the relationship between UI components (as embedded screenshots) and to show component dependencies. I try to follow UML, but I don't care about machine readability and prefer readability over UML compliance.

You can find some uses-cases of those diagrams here (https://dev.to/hediet/create-diagrams-in-vs-code-with-draw-i...).

* Sequence https://plantuml.com/sequence-diagram

* Use case https://plantuml.com/use-case-diagram

* Object https://plantuml.com/object-diagram

* Activity https://plantuml.com/activity-diagram-legacy

* State https://plantuml.com/state-diagram

Sequence and Activity are my most used - beyond the ones above logical architecture tends to be a Draw.io created abstraction that ends up in a Google Doc... stuff like this: https://camo.githubusercontent.com/f14ac82eda765733a5f2b5200... (not one of mine)

Hand drawn. I like the idea of building diagrams I just tend to find that:

* It's a lot of work to make them look right.

* They become outdated SO quickly. They're dangerously misleading as often as they're useful.

* Lots of people like to create diagrams, nobody likes to maintain.

Hand drawn dated diagrams have a sort of built in advantage that people will assume that it's not been kept up to date, especially if it's scruffy. Also they're quick.

I like the idea of generated diagrams better than drawn diagrams but unfortunately the software just isn't there yet.

Even when you can do it, they usually look shit because the program won't layout nearly (e.g. E/R) and you can't integrate changes to the source (e.g. tables) to annotations/tweaks.

The C4 Model looks pretty good, it's like a very simplified UML. The main selling point for me is that it's very intuitive to understand without knowing anything about it in advance. However, I don't have much actual experience with it so far, so I'm still not certain it's the best solution.

https://c4model.com/

Flow chart, sequence and class diagrams are the ones I use the most in my current job.

In source, I generally use Mermaid[1] as its syntax is easily maintainable and understandable. And our documentation (mdBook) is written in markdown and can render Mermaid via a plugin[2].

When drawing quick diagrams during online communications, I use Excalidraw[3] as it's easy to use and has a nice whiteboard style to it. When I'm with my team (pre-covid), whiteboard or paper did the trick.

[1]: https://mermaid-js.github.io/ [2]: https://github.com/badboy/mdbook-mermaid [3]: https://excalidraw.com/

If you have complex interactions sequence diagrams can be a hugely helpful communication tool. I use https://sequencediagram.org/ quite often. It's a free, in-browser tool that lets you create/edit/export diagrams using markup. Takes some getting used to but I much prefer it to dragging arrows around manually.

I was thinking today we need a communal collection of diagram templates that we can reach for instead of re-making our own each time.

I shouldn’t have to re-adjust my mental model because of some stylistic/level-of-detail decisions by the author.

These diagrams would be interactive too.

Many systems are very similar in what they do. There are many times I am asking myself: “but how is this different from ”.

Think about categories like append-only logs, search indexing, web requests, git trees, etc.

I’d love to be able to diff against two diagrams to the same problem and see how the approaches differ.

Mental model often formed much more around what kind of data flows and interactions happen between components.

As a big fan of Domain Driven Design I found "domain storytelling" a useful technique when adapted to software systems.

With these diagrams it was much easier to convey complex systems and their temporal couplings. Especially to higher Management as they can actually "read" how the sequence of events flow.

Try it out and see if it can be another tool on your belt.

===

https://domainstorytelling.org

I'm surprised there's only one other person in this discussion who has mentioned swim lanes. They are incredibly useful!

Swimlanes are basically process flow diagrams (aka flow charts) but with lanes that indicate which actor or system performs each process.

At my company, if an engineer gets tasked with a logically complex feature or a feature that involves multiple different systems, then we will often require them to use swimlanes to diagram out their new feature before they start coding it. The flow chart makes it easier for the business owner to double check the logic before it's implemented. The lanes help the engineer better understand more intuitive ways to organize their code (classes, methods, etc) and the interactions it will create. Without the lanes, code organization on logically complex features involving multiple actors can go off the rails pretty quickly.

For database table specs we use ERDs.

https://plantuml.com/, https://graphviz.org/ and recently Graphviz based https://diagrams.mingrammer.com/

I hate Visio so much, I do not hate any other software that much.

I am very fond of using graphviz (https://graphviz.org/) to draw the finite state machines that my programs interact with. For example, this is a description of the state machine inside the Linux kernel audio subsystem, as it was several years ago: https://source.chromium.org/chromium/chromium/src/+/master:c... You can draw it using ‘xdot’ for something interactive or with ‘dot’ for a static png or svg file.

Sometimes I use DRAKON. It's useful for untangling complex algorithms.

[1]: https://drakonhub.com/en/drakon

My main diagramming tool is Microsoft Visio, but I also use Excalidraw and AsciiFlow when "sketching" rough ideas.

I create architecture diagrams - these show how different components fit together, what network boundary they reside in etc. I like Visio for these in particular, because I can use different images to represent each component - I find it makes the diagrams easier to read.

I create "security diagrams", which are basically just a box for each significant component, with lines and arrows showing the direction of network communication and what protocol and port are used. These diagrams also show what kind of authentication is used.

I create use case diagrams, to show the actions that different roles within the system can perform.

I create very basic inheritance diagrams only to show different roles within the system.

I occasionally create action diagrams, if needed to help understand decision flows.

I occasionally create sequence diagrams, if needed to help understand the sequence of interactions between different components/modules/actors.

I very rarely create class diagrams - if I have to do this, it basically means the design is too complex (e.g. too much use of generics, too much use of inheritance etc).

UML is far from dead, it's just that people don't doggedly churn out and maintain every kind of UML diagram for every part of every system - they are really useful for explaining a few specific parts of systems.

The only uml diagram I've really used in the last decade or so is the sequence diagram - for describing use cases for network message exchanges. And even that is in powerpoints and on whiteboards. I can't imagine ever formally documenting anything that way. Too bulky.

I try to avoid over-use of inheritance, so class diagrams don't get used for that. Mostly I use unstructured boxes and arrows for entity-relations, and don't worry too much about notational rigour.

I like the C4 model because it forces me to think about the right level of abstraction for the diagram's audience. It also has very few core building blocks and thus is very easy to learn. I just wish the tooling around it was better :)

I'm a big fan of sequence diagrams, especially those that can be generated from markdown-like syntax. I use Lucidchart at work, but there are a few free options as well -- in this comment I'm trying to advocate for the concept rather than a specific tool.

Sequence diagrams, to me, give the benefits of a flow chart, but with a much tighter explanation of the actual flow and relationships. You can read them from the upper left corner to the lower right, just like (western) writing. You get not just the entities involved, and not just the way they are connected, but the _ordering_ of those connections, which I find super helpful. The concept is simple enough that I can hand draw it on a whiteboard or scrap of paper, and for electronic formats, if you generate these from markdown you now have the same data in both a visual and textual format (handy for folks who have a harder time accessing pure visual presentations), and auto-generation from text makes it easy to update and so more likely to maintain as the system changes.

We dogfood our own tool, AppMap (https://appland.com/docs/how-it-works.html) which records executing code into JSON files and then turns that data into interactive diagrams and analysis.

We also think Mermaid is a great project. I want to try the entity relationship diagrams next.

When useful:

Component diagrams, what is connected to what?

Activity diagrams, what are the activities that happen, and have they got names?

Sequence diagrams, so microservices on top of microservices, hmm please show me how you get item x?

State Diagram, are you sure you have got all the possible state transitions?

ERD diagram, Chen style, I don't like it when the look like SQL tables (maybe we don't have/want/need a relational database, so lets not start shaping it like one at the concept stage). The physical/logical models I don't see much value diagramming.

BPMN can be useful alternative to Activity diagrams sometimes.

edit: left off Use Case diagram, so simple yet seen teams struggle so many times to articulate this.

A key thing about doing a diagram or document is that they force you to clarify your understanding. Another rule of thumb is if you are struggling to keep you docs/diagram in sync with your implementation, you have likely made you docs too detailed, its a high level map to guide not a detailed set of instructions on how to construct.

I like bpmn workflows. Especially with the Camunda editor. Not for execution, but for quickly drawing up logic and flows to explain how I suggest we do things. Those diagrams are complete enough to encompass everything: low-level logic to high level cloud and system architecture.

And everyone understands them without any help or explanation.

I've recently started using Terrastruct, which I've come to enjoy as I feel like I can quickly put together business logic and share it with the team without the tool getting in the way: https://terrastruct.com/

I use excalidraw for high level diagrams. Love the handdrawn feel to it. There's a feature to collaborate too but I haven't tried it yet.

I use the FMC - Fundamental Modeling Concepts language to draw systems and architecture diagrams. The beauty of FMC is that only two node types exist, both having very clear semantics (depending on which of the 3 diagram types you draw/read). In a systems diagram a sharp rectangle represents an actor and a rounded rectangle/circle represents a persistent/volatile memory. You can only ever connect an actor with a memory (space), I think it’s called a bipartite graph.

My university took part in its research (less nowadays) and I’m really glad I had the chance to learn it. I still use it at work.

[0] http://www.fmc-modeling.org/

Nothing most of the time. Maintaining diagrams is pain and rarely reflects reality. We have all our services in AWS and it doesn't take long to trace backwards from DNS if I actually don't know how something works.

TikZ:

- http://www.tcs.uni-luebeck.de/downloads/mitarbeiter/tantau/2...

- https://texample.net/tikz/examples/tag/diagrams/

- https://www.overleaf.com/project/5c73f8d11e30574803429a04

I mostly draw data flows. Draw a bunch of boxes representing different services and sometimes different components, and labeled arrows describing where events/data flows.

When that's not sufficient, usually a sequence diagram adds a whole ton of clarity

For reviews with new people, a limited ERD is handy, mostly to show where the 1:n or n:n relationships are

I somewhat frequently write truth tables to get a good breakdown of different usecases

I use web sequence diagrams for my sequence diagrams, but mostly everything else I'm drawing by hand in paint 3d with the surface's nice pen drawing

I use different hand-drawn notations for different purposes - they should be intuitive so people would understand without learning anything.

The major problem I see in UML is it tried to unify things, but in reality, we use diagrams for different purposes and different audiences. The same idea could be found in C4.

I don't strictly follow C4, instead, I choose notions I find suitable for the audience and context (eg: architecture for tech people, domain modeling for domain experts, or just abstract ones help myself thinking)

Control Flow diagrams to work out logic, turn that into pseudocode in comments, then start implementing under each comment.

Also, ER diagrams because it's easy to translate drawing to normal form

We are makers of gleek.io diagram maker https://www.gleek.io/ and we use this tool internally as well.

When I create diagrams I prefer typing than drag-and-dropping and gleek.io is pretty fast.

You can check the diagram examples:

* Basic shapes https://app.gleek.io/diagrams/basic

* ERD crows foot https://app.gleek.io/diagrams/erdiagram

* UML class diagrams https://app.gleek.io/diagrams/class

* UML sequence diagrams https://app.gleek.io/diagrams/sequence

Recently we made also video tutorials, hopefully it helps when you are learning to work with a tool:

https://www.youtube.com/channel/UCMl_1_jjnhgPAsRBuJ0yzAA

Feel free to ask anything, happy to help!

Visio. I like the large amount of styling options, installable Azure component packs.

https://www.nomnoml.com/

http://chartmage.com/index.html

https://swimlanes.io/

https://dbdiagram.io/home

I found there are two types of diagrams I lean on, almost always for higher-level explanation-style documents:

1. System architecture 2. Flowcharts

NOTE: I don't try to mix the two. Architecture diagrams are the what, not the how. I find a lot of people try to mix them.

Beyond this, sequence diagrams are useful.

I use these for explanatory documentation, mostly. Like, we have a "architecture guide" for each service we maintain, that usually contains a system architecture diagram, and maybe a flowchart of the "happy path" processing. But these are simplified versions things... like, I usually leave configuration details, like networking and access control out of the architecture guide, and just focus on "what services are interacting with each other directly".

Also, LucidChart has an "AWS import" method, that actually works well, but can be a little like drinking from the firehose. It's a solid tool, but mostly as it's own kind of reference document, like, API documentation for your AWS stuff.

I find that if problem is formalized enough that it could be mapped to specific diagram schema it's actually easier just to start coding it.

But before the formal idea is developed I just sketch in whatever diagram grammar seems most appropriate for the problem.

We don't really use diagrams for formal communication. Most formal discussions are around concrete schemas and API:s.

To answer my own question (I forgot to mention some):

* ERDs

* UMLs sequence diagram

* State diagrams

* JJG's VisVocab (for diagramming interaction, i.e.: screens and actions): http://jjg.net/ia/visvocab

* And some (not well defined) type of architecture diagrams

* Sometimes a branching diagram to explain a hairy git branching issue to a co-worker

I used a lot of Objectory and UML diagrams in the nineties, mostly for specification and presentation reasons; don't remember when I used one last time; must be more than ten years ago; from my point of view UML is overkill most of the times; usually takes more time to explain to people what all the sophisticated symbols mean than e.g. simple block diagrams; and systems tend to be so big these days that UML diagrams become too big and confusing; we had the same evolution in hardware development; schematic diagrams were almost completely displaced by hardware description languages (such as Verilog) because systems became much too big to be decently modeled with diagrams. EDIT: it's worth taking a look at this article: https://modeling-languages.com/uml-opinions-creators/

UML component, deployment, state chart, class, use case and activity diagrams. I mostly use PlantUML, which is, due to its textual source notation, embeddable into Markdown or AsciiDoc files and are therefore comparably easy to version.

PlantUML works best with sequence diagrams because automatic layout is much easier ("sequential") for them.

I mainly use diagrams in documentation and not in specification or development (although tools I am learning to use, such as Alloy [0], for specifications do generate diagrams of the state).

In documentation I typically use a mix of ditaa[1], mermaid[2], and graphviz[3]. I used ditaa for architecture diagrams, a mix of sequence, flow chart, and ER diagrams in mermaid to explain protocols or interactions; and I use graphviz usually for datastructures or dependencies, etc.

[0] https://alloytools.org

[1] https://ditaa.sourceforge.net

[2] https://mermaid-js.github.io/mermaid/#/

[3] https://graphviz.org/

I use ER diagrams to model data structures, even if they are not stored in a database. I find them to be much clearer than class diagrams for example, and they help to keep an overview of everything. Otherwise, I sometimes use activity diagrams to model some complicated logic but don't use anything else of UML.

If we talk about professional use, then Powerpoint (many years ago), then Visio (also many years ago), then yEd (by yWorks, https://www.yworks.com/products/yed). Then there are a ton of specialized open-source tools, with varying quality. Mermaid improved a lot. PlantUML has a lot of options, but I would not use it professionally. draw.io has also plenty of options, but has some usability issues in the frame of a frequent, professional use.

For anything UML-related, Enterprise Architect is quite good, but boy you better know UML. That ain't user-friendly in the least. But super powerful and there are a few more like that out there with somewhat limited free versions.

Long story short, my best choice is yEd. And I still reach out to Powerpoint every now and then.

Semi smart-ass answer: Whatever is the simplest one to communicate what I'm trying to say.

I don't strive to be 100% compliant with a given methodology, I see those as diminishing returns. Class, sequence, architecture, a bunch of lines and boxes, whatever does the job.

It depends on your audience & message!

I use mermaid: https://mermaid-js.github.io/mermaid/#/

And excalidraw: https://excalidraw.com/

Years ago we found it useful to generate a database diagram. Each table had its own box with the columns in the table, their data types, default values, etc. Lines would connect the boxes indicating foreign key relationships. Back then we were using oracle. The program would connect to the database and run DDL queries to build the boxes and lines. Then we could group the boxes (all the user tables over here and colored blue) manually. Periodically we’d generate a large pdf and send it to the print shop to be printed and hang it up in our work area.

I can’t remember what program we used. But now we are on Postgres and we talk about creating a database diagram again since we found it so useful. We just haven’t found a good program yet.

Sequence diagrams are about the only thing for a long time.

Otherwise nothing much... random visio-ish things made in draw.io or sometimes scribbled out on the fly during presentations using a wacom tablet. I tend to prefer words, code snippets and config to explain my stuff these days.

Markdeep[0] from Casual Effects has a way of drawing diagrams using extended markdown.

I used it to write this document with two diagrams: https://loan-free-ed.neocities.org

Other tool I like are PlanetUML[1], BoUML[2] and Modellio[3](it is very heavy though on system resources!)

[0] https://casual-effects.com/markdeep

[1] https://plantuml.com

[2] https://bouml.fr

[3] https://www.modelio.org

Flow charts are huge for me. It's a good way to show a non programmer my understanding of a process they have explained. It also helps me code a little clearer when the business logic is less intuitive.

Also truth tables if I have to work with booleans in excel.

I end up doing a lot of software infrastructure architecture diagrams. The product I work on has a lot of components and interacts with a lot of things, and the people we sell it to always want that mapped out. Frustratingly, they don't ever seem to be able to comprehend the generic diagram, and require it to be remapped into their actual infrastructure, which I never have any idea about, and am usually at least two Kevin Bacon's away from any kind of access to.

Otherwise I do a lot of off-the-cuff statemachine and sequence diagrams, I guess you would call them. Very often literally scrawled on a napkin and then photographed with my phone.

I used to make my diagrams in draw.io but I find that I spent way too much time fiddling with the way the diagram looked rather than the thing it was modeling. Also it is a huge pain to have to go back and make revisions to the diagram. After presenting diagrams to stakeholders they would always ask for changes and I would end up having to redraw everything.

I recently stumbled upon code to diagrams tools like app2code and plantuml. I really enjoy this because I can focus on the model and not the aesthetics. Also making revisions to code is a lot easier than fiddling around with draw.io.

Does any one have any tools like this they can recommend?

https://draw.io But dbdiagram.io looks amazingly easy to use. And so are the rest of the suggestions. I also realize that I don't use UML with draw.io:)

I realized that the only UML diagrams really helped me back in school were behavioural diagrams: sequence diagram and activity diagram. They describe the hard parts of programming/complexity.

Structural diagrams: do not "solve" anything really. (I know, they might be good for docs...)

Also recently I started to think in terms of events. Look up FRP, "real OOP" and Cycle.js.

For these, there is no standard diagram yet, so I am came up with my own - still under change.

For that, I started to use Lucidchart, because its available on mobile/tablet as well in browser as desktop view and it gives full functionality.

It's also really nice & snappy.

This [1] is not something I use but something that's been on my radar for a while and I would like to investigate:

"IFML provides ... tools for the definition of Interaction Flow Models that describe the principal dimensions of an application front-end."

Just a few days ago there was a thread about the death of UML... like anything from omg.org, I suspect there's a useful subset to carve out that could be useful to model applications.

1: https://www.omg.org/spec/IFML/1.0/PDF

I actually make a diagramming library for the web, called GoJS, so that other programmers can quickly add interactive diagramming capabilities to their web apps: https://gojs.net

So I make all kinds of diagrams, mostly as demonstrations. When developing a library itself, especially one where there are phases (Graph Objects must measure themselves and their parts, and draw in a certain order, and not more than they need to), state machine-style and flowchart-style diagrams are awfully helpful.

Activity diagrams. I find that they are my go to when I want to communicate how something will work. This is when we are considering a modification of something that already exists or if the idea is new but well defined.

I'll use draw.io usually but if it's to clarify something small, I'll just draw it on my notebook and snap a photo of it.

That's what I love about the activity diagram. Communicates a ton of information in a form that even if you've never seen it, it will be pretty intuitive. And creating it is also super lightweight.

I like sequence diagrams and state diagrams (well just straight finite state automata). They bring an extra layer of description that is otherwise very hard to extract from the code.

I draw them with Plantuml. Text input is really a must have for me. On crowded diagrams it may be difficult to fine-tune the layout though.

I still sometimes do class diagrams, although I do not find they carry much info compared to the code. The meaning of arrows is ambiguous and they're too verbose. APIs are better documented with e.g. Doxygen.

C4 model helps for existing architectures. I use Mural for that.

Any diagrams. After learning about the uml and other ideas and trying things in practice over the years, I found that any diagrams is better than no diagram. But also a diagram that shows what you want to show is better than a diagram which complies with a specific idea/standard but may not represent what you need. Need to mix sequences and inheritance on one diagram for some reason? Just do it (making sure that there correct annotation / legend available)

SDL for state diagrams (https://en.wikipedia.org/wiki/Specification_and_Description_...),

UML seq. charts to develop the SDL state diagrams.

Object Role Modelling for database schema design (https://en.wikipedia.org/wiki/Object-role_modeling)

I'm mostly producing component diagrams where we detail communication interfaces and services responsibilities; those are stable, long running and broad enough that one they don't become immediately obsolescent and still are granular enough that they can convey useful information to whomever reads them

we also do produce some reverse engineered code map with doxygen here and there, so we can cut down cross dependencies and dependency cycles as the codebase matures

We use a lot of sequence diagrams.

So much so that thanks to https://bramp.github.io/js-sequence-diagrams/ I've got a Netlify-powered static site for creating them interactively at https://sequence-diagrams.netlify.app/ using their JavaScript library.

I generally design my software in StarUML and generally use class and sequence diagrams.

I'm not using it as a UML tool strictly, but being able to document everything, generate the document in HTML and being able to store it alongside design documents help me a lot.

Small algorithms are hand drawn first, and documented extensively in code. If they're crucial for the research I'm doing, I carry them to the same StarUML document too.

Architecture and Data flow diagrams. Usually I sketch it out on paper and transcribe it to Lucidchart. Recently, I had to troubleshoot connectivity issues in Amazon RDS in a private subnet with AWS Data Migration Service. This was a regulated environment with heightened isolation. I was only able to figure out the problem once it was on paper and could see it visually with the various Security Groups described.

I frequently communicate architecture with diagram that simply contains following three things: - boxes (rectangles with text in them) - arrows connecting these boxes - and some brief text to convey any architecture/ideas

Apart from this, sometime I also use "sequence diagrams" - vertical lines representing systems/modules to illustrate the sequence of flow of any system/user action.

We use PlantUML with markdown in our internal wiki. The pros are a) that you can understand the markdown on its own, b) we can diff changes to the diagrams, and c) the source code is very small. The main downside is people are more used to drawing than coding diagrams (even developers), and the output quality of PlantUML leaves a LOT to be desired, by today's standards.

Sequence diagrams, state transition diagrams, and network diagrams provide the most value to the development teams I have been working with.

I made this tool 15 years ago: http://move.rupy.se/file/logic.html

It has been used for everything from SQL design to quest scripting in games.

I don't use it anymore because I made my own JSON database: http://root.rupy.se

dbdiagram.io for ERDs these days:

https://dbdiagram.io/home

We visualise certain data structures (DAGs and trees) for debugging and documentation with https://graphviz.org (EPL) and https://yworks.com/yed (proprietary, freeware).

Mostly architecture diagrams, data flow diagrams, flow charts, sequence diagrams and ERD. Mostly they are used as an accompaniment for the brainstorming and design discussions and, in some cases, to serve as easy reference for future. We mostly use draw.io and Visio as the diagramming software in our teams.

* Simplyfied subset of UML (sequence, state ...) - on whiteboard (pre covid), now google docs. These diagrams do not last long. We're using them for discussion and some documentation. * ERD using our tool (we eat our own dog food). This one is crucial. Code and migration scripts are generated from it.

For front-end to back-end web development, UI/UX-friendly collaborative diagramming: https://whimsical.co and https://figma.com (new FigJAM tool).

I'm usong diagrams.net all the time. It is even my go to explanation tool in meetings (virtual or not). Just open a window, start drawing concepts and linking them. I found out that it makes it much easier for the audience to grasp what is happening rather than already made slides.

I use draw.io for high level architectural diagrams, both for oop code and infrastructure. When on site i use whiteboards and pictures of them, then if time allows i move them over to draw.io. I almost never draw implementation diagrams. These can be extracted with tools like doxygen.

For quick sketches of architectures, try https://isoflow.io (a tool I'm building). It's designed with a strong visual language in mind.

Most often used are process diagrams: My preferred tool here is the great text editor based: https://sequencediagram.org/

Rich drawings in draw.io.

Sequence diagrams in PlantUML (using the awesome VScode extension)

POWER POINT.

Because I just want some shapes, lines and clip-art to communicate an idea clearly, quickly, and informally.

I remember the UML days and their endless variety of turgid tools, don't want to re-live those experiences.

Sequence diagram with PlantUML and deployment diagrams with Gliffy. Every other type of diagram has fallen by the wayside, over the years. PlantUML with Visual Code is a breeze and makes life easy.

ASCIIFlow and Draw.io as both are not bound to some specific program and you can commit both to git.

UML is pretty much dead, so 'standard' diagrams are not worth the effort unless contractually requested.

Most important UML diagram as per my experience are StateCharts, even more than Sequence Diagrams, it can indicate behaviour, including time outs, and possibly exceptional circumstances.

I don't use strict UML, but I still find it useful to do work with block diagrams of systems to show relationships of major components.

I used to use Yed, but now I like drawio.

Monodraw [https://monodraw.helftone.com/]

I really like it simplicity in creating charts

Archimate for high level architecture, uml for more detail, and masala diagrams (that's what we're calling them right?) in ppt for marketecture

don't think of a "luddite" comment, but, apart some online tool, like websequencediagrams or drawio, I find a necessity to just doodle some informal diagrams with pen and paper, mostly to understand the "hi-level" architecture of a solution (where "hi-level" spans from source modules dependencies to microservices / db dependencies to "macro" stuff)

https://mbarkhau.keybase.pub/asciigrid/

> While UML's inheritance diagrams have been dead to me for a long time, I still like the sequence diagrams.

Common sentiment, I suspect.

- Entity-Relationship Diagrams

- Sequence Diagrams

- State Diagrams

- Activity Diagrams

I use PlantUML to render all these, with the added benefit of being able to produce it programatically.

UML and Entity Relationship ones.

Most designs can't be planarized that easily, so I don't use diagrams.

I use Sankey diagrams with D3.js for a lot of security architecture work.

I don't use any tools at all. Keep diagrams in my head - if they are too complex for that then there's a different problem to be solved.

Use case, State Machine, Sequence, ER.

plantuml for sequence diagrams, lucid chart for system cartoons

draw.io - it's the best and it stores locally

Boxes and arrows. Occasional pic taken of a whiteboard.

I should write a book on it, maybe give seminars and sell training materials.