3 ms·
> They are just expensive to build, expensive to maintain and go out of date fast enough that they're practically ephemeral. I agree with this if you're using
by Veuxdo 3y ago
> They are just expensive to build, expensive to maintain and go out of date fast enough that they're practically ephemeral.
I agree with this if you're using drag-and-drop diagramming tools. Diagrams-as-code is a potential solution IMO: https://www.ilograph.com/blog/posts/its-time-to-drop-drag-and-drop-diagram-tools/ https://www.ilograph.com/blog/posts/its-time-to-drop-drag-an...
- steve_adams_86 3y agoI’m a fan of systems where the diagram and code can be changed on both sides, too. Though they lack flexibility and require a sort of convention or framework to bind both sides. Often they can work incredibly well but tend to have a narrow use case. Something like XState and the Stately studio editor comes to mind; it’ll generate state machine diagrams from code or vice versa. But it only manages state charts. I’m not sure how you could create something similar with more broad applications. Though, maybe that’s not necessary or necessarily a good idea anyways.
- kandros 3y agoI’ve used old xstate visualizer (like 4 years ago) as a communication tool to review flows with domain experts before implementing something, made conversation and spotting problems so easy