Ask HN: What do you use for diagramming in software engineering?

For more long form docs I tend to use a mix of LaTeX's TiKZ (though I used to use PSTricks) for block diagrams and for a somewhat faster workflow I've used some of the diagramming tools which integrate nicely into an asciidoc based document. That can be graphviz, blockdiag, seqdiag, etc ( https://asciidoctor.org/docs/asciidoctor-diagram/ has a decent list of some of the options).

With any option it's easier to quickly sketch something out than it is to have some clear well organized diagrams which don't need any external context to understand.

The diagramming tool is a minor consideration except it should be easily editable by someone coming along later. The important thing isn't the tool, but that there is a common, known place to look and collect the info for the team. It could be as simple as a shared folder as long as everyone agrees.

In general, I write and try to encourage "tech memos" that are short of capital-D official, complete Documentation, and instead focus on capturing the high-level view of some scoped aspect of the total system. Memos that cover say a walk-thru of one type of operation through the entire system, how a single feature interacts with the larger system, or a tricky bit of analysis, logic, or assumptions on some key point; all tend to be popular reading. Whiteboard pics are often included just for convenience if needed too.

For block diagrams that illustrate relationships between components as a sort of directed graph, I prefer Omnigraffle (on OSX). It's fast and effective, easy to label boxes, lines, and interactions, and supports exports to pdf and png for quick sharing. Where omnigraffle falls over is in terms of its popularity and accessibility. You can't really review the diagram source as a part of the code review process, and the output diagrams are not useful to the visually impaired. Popularity is a factor because even if a dev knows some piece of block diagram software well, it's likely that they know a different one than anyone else. For that reason, we're not prescriptive about the tool used on our team, only that some form of block diagram is included with the documentation for a feature or component.

For sequence diagrams I use web sequence diagrams, for which I hold a commercial license. These diagrams are great for illustrating different workflows, with the caveat that we generally need several very similar diagrams to explain even the simplest features. These also benefit from having a straightforward text format that can be shared as a reviewable part of the source tree, and which can be read and edited by the visually impaired. Sequence diagrams are a more effective tool for demonstrating the veracity of code against a desired specification than block diagrams are, but understanding the top-level component layout is generally a prerequisite.

Not sure about the general popularity of either of these, but they've been an effective toolchain for me so far.

Both work, I ended up choosing LucidChart and we are now testing it with the team

http://casual-effects.com/markdeep/

[1]: https://en.wikipedia.org/wiki/Dia_(software)

Primarily though I use sparx enterprise Architect. I've been told it's outdated, others don't like the ui, but honestly all my models are in one place, including wire frames and use cases. I enjoy use it. It's roadmap creation support I do not like, like a poor Gantt (at least last time I tried it)

https://www.yworks.com/products/yed

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