Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Architecture diagrams are great and do indeed enable better conversations. They are just expensive to build, expensive to maintain and go out of date fast enough that they're practically ephemeral.


> 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-an...


I’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.


I’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


Also, in order for them to capture appropriate granularities of detail, they take a lot of time and conversation with readers.

I usually go with as little graphs as possible and prefer to write text; it can capture more, better, faster, and be more iterable. For specific areas like state machines or packet sequences I will drill into graphical representations more but otherwise... eh. Text wins.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: