[HN Gopher] Devs need system design tools, not diagramming tools
___________________________________________________________________
Devs need system design tools, not diagramming tools
Author : argoeris
Score : 90 points
Date : 2024-07-16 15:09 UTC (7 hours ago)
(HTM) web link (thenewstack.io)
(TXT) w3m dump (thenewstack.io)
| gtirloni wrote:
| I read the whole article and it has great points. Almost nodded
| the whole time. However, I couldn't identify whether an
| alternative exists today.
| anotherhue wrote:
| Maybe checkout https://c4model.com/
| imglorp wrote:
| It sounded like it was working up to a C4 pitch but never got
| there. It bears a look exactly for this post's title.
|
| https://c4model.com
| Veuxdo wrote:
| Almost all of his complaints stem from using generic drag-and-
| drop diagramming tools. A modern take on system diagramming,
| like Ilograph[0], solves most of these issues (IMBO).
|
| [0] https://www.ilograph.com
| qznc wrote:
| I believe the answer is to have a single model of everything.
|
| You can build the model from whatever: Draw it with a GUI,
| query your server infrastructure, analyze binaries, collect it
| from databases, parse it from documentation, process your
| issues, etc. The important points is to merge all the
| information into a single model.
|
| You cannot represent this model on a screen in any meaningful
| way. Instead you can only get certain "views" into it to
| understand an aspect or answer specific questions.
|
| Does it exist today? Many tools and processes have been
| developed to achieve it. For example, "Model-based systems
| engineering" is a very formal approach. I have yet to see it
| realized in practice though.
|
| I'm pretty sure it isn't a single tool or process though. By
| definition it integrates with nearly everything and that means
| a lot of customization. You won't get it get it off the shelf.
| Veuxdo wrote:
| > You cannot represent this model on a screen in any
| meaningful way. Instead you can only get certain "views" into
| it to understand an aspect or answer specific questions.
|
| It sounds like you're describing:
| https://www.ilograph.com/blog/posts/concrete-diagramming-
| mod...
| qznc wrote:
| It looks quite limited in what kind of diagrams it
| produces. What about a class diagram, a state machine,
| timing behavior, etc?
| AnimalMuppet wrote:
| The problem with "a single model of everything" is that it is
| an inferior tool.
|
| It's a drawing or diagramming tool, but the stand-alone
| diagramming tools are better.
|
| It's a text composition tool, but word processors are better.
|
| It's a code writing tool, but IDEs are better.
|
| In every single thing it tries to do, a specialized tool is
| better. So this single tool needs to be close enough to the
| best in every category in order to not be a boat anchor
| holding you back. So far, nothing has come close.
| qznc wrote:
| Yes, that is good point. It might be reason why it fails in
| practice. Whatever view one produces from a single model,
| it will look crappy and cheap compared to the Powerpoint
| slide of someone else. It might be more truthful and more
| up to date, but it isn't as persuasive. Persuasion is what
| a presentation is ultimately about: It should influence the
| behavior of the audience.
| TeMPOraL wrote:
| Nothing stops us from using specialized tools in this case.
| They just need to not work on "single source of truth" of
| their respected domain, but on a projection of a single
| artifact into relevant dimension. Devil's in the details,
| of course, but at least with IDEs I can tell with
| certainty, based on my experience, that sticking to editing
| directly the single source of truth plaintext codebase is
| wasting much more time and cognitive effort than IDEs are
| saving us.
| riiii wrote:
| UML had the idea. But instead of focusing on the visual
| aspect they went bananas on trying to turn it into some sort
| of a programming language.
|
| Also the design tools for it were hilariously expensive and
| notoriously cumbersome.
| Jtsummers wrote:
| That aspect of UML fell out of the development of CASE
| tools. A very mixed bag of results.
|
| https://en.wikipedia.org/wiki/Computer-
| aided_software_engine...
| kitd wrote:
| > Does it exist today?
|
| Not sure, but IMO a dataflow diagram from good ol' SSADM got
| a lot of the way there. Unlike a lot of the modern techniques
| which model (groups of) deployed components, DFDs were
| strictly logical and functional and included data stores and
| users as well as functional components. So it was possible to
| model data in flow and at rest, and the characteristics of
| each, including where it crossed system boundaries.
|
| IMO this was the best diagram format to get an overall view
| of the system, or reveal which areas needed further analysis.
| 9dev wrote:
| This is something I that's been living in my head for a few
| years now--and no, it does not exist yet. I'm also convinced
| the only way to get it right is to have a single graph,
| modelling the entire system, and apply filters on the graph
| to get only the nodes you're currently interested in, then
| have different diagrams produced from that as the output. How
| else would you describe the flow of packages from the
| internet through the firewall, what the logical network looks
| like, and which physical location things are located at?
| These questions all interfere with each other on a conceptual
| level, yet are all conceivable using different attributes of
| the same connected graph nodes.
|
| It's very complex, very interesting, and lots of work.
| halfcat wrote:
| I came to the same conclusion, and the closest thing I've
| found is using a graph database.
| dennisy wrote:
| Great post but lacking an answer. I guess we are yet to find one!
| sam1r wrote:
| Agreed!
|
| If every acknowledgement of the(or any imo) issue at hand, was
| accompanied with a minimally viable solution (even if it
| doesn't work) -- as the defacto standard for providing critical
| feedback..
|
| As long as some effort is put in towards a countering possible
| solution in response-- I truly feel that we would be closer to
| an end solution.
|
| I guess should this "problem" truly exist.
| Joel_Mckay wrote:
| I think the folks working on constraint programming with
| MiniZinc and Phoenix/LiveView have achieved a fairly practical
| solution.
|
| https://github.com/bokner/solverview
|
| https://github.com/bokner/solverl
|
| https://www.minizinc.org/
|
| YMMV, as I've yet to personally try a toy project with this
| approach. =3
| RcouF1uZ4gsC wrote:
| >Today, we have the technology and knowledge to create tools that
| prevent developers from wasting valuable development time
| deciphering static, outdated diagrams,
|
| One issue is that diagrams in general are pretty universal. As
| long as your tool can makes shapes and connect them, you can use
| it for any kind of architecture. For example it will work flow
| charts for 50 year old Fortran to UML from the 90s to
| microservices diagrams from now and I bet to whatever is common
| 50 years from now.
| sam1r wrote:
| >> >Today, we have the technology and knowledge to create tools
| that prevent developers from wasting valuable development time
| deciphering static, outdated diagrams,
|
| "Outdated", imo, is subjective to the content and is bias'd by
| the time since creation.
|
| As long as wireframed thought is the bare skeleton, the
| diagrams are merely a read-only user interface to communicate
| to a particular end-user audience.
| jawns wrote:
| This reminds me of the following:
|
| * Devs: We need a better language than Javascript as the lingua
| franca of the web!
|
| * Users: Sure, use whatever language you want -- just make sure
| it compiles to Javascript, which is already the lingua franca of
| the web.
|
| Keep in mind that the consumers of technical diagrams are often
| non-technical folks. And they don't care about how they get their
| diagrams. They just want to be able to understand, at a high
| level, what's going on in the black box.
|
| You can either convince every single one of them that devs need
| to focus on better system design tools ... or you can continue to
| give them the diagrams they want, just using a smarter process to
| generate them.
|
| Or you can treat them as entirely separate problems, because
| fundamentally system design tools are building tools, and system
| diagrams are communication tools. In most cases you can improve
| them independently.
| BadHumans wrote:
| > * Users: Sure, use whatever language you want -- just make
| sure it compiles to Javascript, which is already the lingua
| franca of the web.
|
| I don't think users are saying this and I don't think they care
| as long as it works.
| Jtsummers wrote:
| Exactly. Users don't care about the underlying tech as long
| as it works and works on the platforms they're using and with
| other systems they're using. That's it. When users start
| caring about the underlying tech, you need to actively
| dissuade them unless there is a _sound_ technical argument.
| Otherwise you end up with people insisting on using DOS for
| enterprise applications in 2024 because that 's what they've
| used since 1984 (wish I hadn't experienced this).
| mschuster91 wrote:
| > Otherwise you end up with people insisting on using DOS
| for enterprise applications in 2024 because that's what
| they've used since 1984 (wish I hadn't experienced this).
|
| DOS as a tech stack is ludicrous (unless you're working in
| embedded/industrial scenarios, but hey, at least you can
| command a significant paycheck in exchange for that level
| of horrors).
|
| A terminal user interface however? Absolutely not,
| particularly if your userbase often has literally _decades_
| worth of muscle memory. Banks, governments or travel
| agencies (see an example for Amadeus here [1]) live and die
| with the "legacy" TUI.
|
| [1] https://servicehub.amadeus.com/c/portal/view-
| solution/832976...
| Jtsummers wrote:
| If this were a data entry tool, I'd agree on the TUI
| part. It's a data processing tool and a bottleneck. There
| have been several replacement efforts, all canceled (your
| tax payer dollars at work, these were government
| contracts long before my time on the system). It should
| be 1-3 networked services (common data store, different
| tasks making 3 services a logical outcome rather than 1
| service doing too many things but it's small regardless
| so either way is reasonable).
|
| The customers in this case feared change too much to
| accept anything that wasn't exactly what it was
| replacing. Which meant that there was no point in doing
| the work.
| mschuster91 wrote:
| > The customers in this case feared change too much to
| accept anything that wasn't exactly what it was
| replacing.
|
| Now, the interesting question is, who gave the pushback.
| Particularly in government, change in the "status quo" is
| feared because it would force the really old ones to
| deviate from a routine they have been living for decades
| - they'd have to basically re-learn their jobs, all for a
| few years before retirement. Others don't want any kind
| of improvement because then the young people, used to
| modern technology, would go and run circles around them
| regarding productivity, which would impact the "oldtimer"
| careers negatively.
|
| And in some rare high-stakes cases, the system is mission
| critical and any kind of deviation from the previous way
| of working can literally send people to prison or cause
| massive monetary damage. Here, everyone wants to keep the
| status quo in order to not awaken the beast, and the
| incentive grows really powerful when it's some old
| mainframe system with tons of undocumented implicit
| assumptions and edge case covers.
|
| Government work in my experience is a whole bunch of
| negative incentives from _all_ levels thrown into a
| blender.
| Jtsummers wrote:
| Reportedly close to 100% turnover in the actual userbase
| (versus the paying part of the government) every 2-3
| years. So it's not about deviating from routine, but
| those users aren't given a voice in the change efforts.
|
| This is an issue with the program management which is
| very common in government. They are too change averse
| even when change is necessary (to satisfy their own
| requirements in this case, the DOS box can't connect to
| the network but they want the system on the network).
| bluedino wrote:
| > Otherwise you end up with people insisting on using DOS
| for enterprise applications in 2024 because that's what
| they've used since 1984
|
| Or Visual Basic and Windows XP
| Jtsummers wrote:
| They had that too.
| jawns wrote:
| Right, they aren't explicitly saying it.
|
| They are, however, implicitly saying it with the position
| that "I don't care as long as it works."
|
| Javascript is available on every modern browser. It's not
| going away any time soon. Migrating to some other frontend
| language, no matter how demonstrably better it is than
| Javascript, is a Herculean effort. Actually, it's more of an
| Atlassian effort, since it would require practically an
| Earth-wide shift.
| factormeta wrote:
| Isn't that what WASAM suppose to be?
| TheRealPomax wrote:
| > * Users: Sure, use whatever language you want, as long as
| it runs in my browser, because that's what I'm already using.
| qznc wrote:
| Well said.
|
| Users: Sure, use whatever presentation you want - just make
| sure it can be shown on a 2-dimensional screen, which the
| lingua franca of presentations.
| bsder wrote:
| Yeah, the PowerPoint-ization is now so complete that people
| can't even conceive that there are other ways to give a
| presentation.
| maccard wrote:
| I disagree. Since Covid pushed us into WFH, the number of
| slide decks I am subject to is trending downwards. Most of
| my presentations these days happen in Miro, or Notion, or
| over a screen share of whatever we're doing. There's still
| the odd PowerPoint but they do have their uses as much as I
| dislike them.
| Detrytus wrote:
| Compiling to Javascript is a really low bar: all Turing-
| complete languages are equivalent, one can be translated to
| another. You could have a Lisp or Haskell compile to
| Javascript. The problem is: everyone has their favorite
| language, so such ecosystem would be fragmented, and Javascript
| is the lowest common denominator.
| canterburry wrote:
| We have the tools and ways to express architecture. The problem
| is no one is bothering to actually learn it and do it well.
|
| Everyone seems to look for answers involving not having to spend
| any time learning anything new.
|
| UML, BPMN, 4+1 view, it can do it all. Just learn it and make
| sure everyone else in your team does too.
| Supermancho wrote:
| Product people will not. So we have the inglorious situation of
| 2 sets of diagrams and notes on the translation between them.
| If the problem was easy to solve, it wouldn't be something you
| can express in a sentence, while simultaneously asserting how
| easy it is.
|
| Some people do not adequately constrain the problem while
| others overly constrain it, conceptually.
| canterburry wrote:
| BPMN was created for product people. UML use case diagrams
| were created for product people.
|
| I don't see the argument why product people don't need to
| learn this. They work in a software organization, they build
| software, they should be expected to know the diagrams
| pertinent to them.
| malfist wrote:
| Use Case Diagrams are only one small part of UML, usually
| the part people learn, but it's way bigger than that.
| pessimizer wrote:
| > I don't see the argument why product people don't need to
| learn this.
|
| They need to, but in my experience, they simply don't want
| to. They want to get the credit for the product, but they
| want to wave their arm and just have its features appear
| without actually specifying them.
|
| I understand because it is hard, exacting work. But as it
| is specificity just gets pushed from product people down to
| the lowest-level person responsible for implementation.
| wudangmonk wrote:
| Honestly ALL diagrams are a dead end, any system where there is
| no single source of truth will be a big hassle to maintain and
| therefore will not be updated which makes the whole thing
| useless.
|
| The only which I can see working as it has already proven
| itself for certain tasks is something like the blueprints from
| the unreal engine but where each node represents something big
| enough to warrant its own node without any no low level details
| like variables, conditionals, loops etc. Otherwise you end up
| with literally spaghetti code.
| SrslyJosh wrote:
| This would be more interesting if there was actually a proposed
| solution.
| qwerty456127 wrote:
| Also GUI design tools like the WinForms designer but for more
| modern toolkits please. VB/Delphi/WinForms were such a joy to
| design and XAMl (let alone web frontent) is such a pain to write.
| ranger_danger wrote:
| I feel like https://plantuml.com/ gets close to what I want by
| being able to make diagrams with code, but for system design what
| I _really_ want is to be able to have diagrams generated directly
| from the code itself, maybe with some extra comments /annotations
| that help it along.
|
| Does anything like that exist already?
| nomoreipg wrote:
| Commented this above, but I actually built a site to auto
| generate up-to-date interactive visual diagrams for codebases.
| It's pretty plug&play, using static analysis & LLMs we generate
| documentation + an interactive system diagram you can
| recursively explore.
|
| https://vision.useadrenaline.com
|
| All the auto-generated diagrams are exportable as mermaid!
| Veuxdo wrote:
| You need to use diagramming tools that are meant for complex
| systems. Almost all of the complaints in this article are caused
| be using generic drag-and-drop diagramming tools.
| hemloc_io wrote:
| What are those tools?
|
| Every big tech job I've had just uses the more generic ones
| like draw.io or maybe an internal only version.
| agumonkey wrote:
| I wonder if modeling/system design people didn't have new
| insights since the last 20 years (when Model Driven * started to
| sink).
|
| Languages changed a bit, more types, more concurrency, more
| functional idioms. Yet I feel we're not going anywhere.
| bunsenhoneydew wrote:
| As others have said the C4 model is a great way to address a
| number of these issues.
|
| I can't find the right video at the moment but Simon Brown
| (creator of C4) gives a great talk about creating his DSL,
| Structurizr, for C4, which he developed during COVID lockdown (if
| memory serves). There are many videos on YouTube of Simon talking
| about "C4 Models as Code" so I'm sure any one of those will
| suffice.
|
| The focus is on creating the model of your system architecture,
| from which the diagrams you extract are a specific projection of
| that model. Rather than a diagram be the main artifact. It's a
| simple but very powerful concept that I'm always surprised isn't
| more widely used.
|
| Structurizr models can also be exported to display as ilograph
| diagrams, mermaid diagrams and more. Also very much worth a
| mention is icepanel, a lovely tool for architectural model that
| implements the C4 model heavily.
|
| I saw Simon talk at a conference in Sydney about 10-15 years ago
| and heard about C4 for the first time in that talk, it's been one
| of the most influential talks I've been to in my career as it
| made a lot of fuzzy things in my head all start to come together
| in a way that just made sense.
|
| https://c4model.com/
|
| https://structurizr.com/
|
| https://www.ilograph.com/
|
| https://mermaid.js.org/
|
| https://icepanel.io/
| nomoreipg wrote:
| I actually built a site to auto generate up-to-date interactive
| visual diagrams for codebases.
|
| It's pretty plug&play, using static analysis & LLMs we generate
| documentation + an interactive system diagram you can
| recursively explore.
|
| https://vision.useadrenaline.com
|
| All the auto-generated diagrams are exportable as mermaid
| bitwize wrote:
| In 1971, M. Bryce and Associates marketed PRIDE, the first
| commercial software methodology for general business use. It was
| originally an entirely manual process using paper forms, but it
| was already far more comprehensive than anything called a
| "methodology" we use today. For example, in PRIDE, every artifact
| of the systems design and implementation process -- each high-
| level requirement, each software module, each database table and
| column, and more -- is assigned a tracking number and extensively
| documented as to its purpose in a unified knowledge repository.
| This was decades before Git or JIRA, and at first it was all done
| by hand, but not for long.
|
| In the 80s, they marketed PRIDE/ASDM, which combines PRIDE with
| Automated Systems Design Methodology, a suite of system design
| tools written in COBOL for mainframes. Far from being mere
| diagramming tools, they assisted in all aspects of an information
| systems design from initial requirements down through coding and
| database management. A key component of ASDM was the Information
| Resource Manager (IRM), a searchable central database of all of
| the information artifacts described above along with their
| documentation. Another component was Automated Instructional
| Materials (AIM), the online documentation facility, which not
| only provided instructions on how to use the system, it also
| provided step-by-step directions (called "playscripts" in PRIDE-
| speak) for each member of the development team to follow, in
| order to see a business system through from abstract design down
| to software implementation and deployment. Provided the
| directions were followed, it was next to impossible to screw up a
| system or subsystem implemented through PRIDE/ASDM.
|
| This level of comprehensiveness and clarity is _the_ gold
| standard for business IS development. And it seems to be nearly
| lost to time.
| danjl wrote:
| Google Slides and Drawings (under + > More...) are great tools.
| They support the diagramming objects, connectors, shared
| collaboration, and integration with the other Google Doc tools.
| They also have great history and diff tools as well as team
| comments, with actions.
| digger495 wrote:
| This is a useless and insipid editorial. I don't want the problem
| redeclared. We know this. We want solutions.
___________________________________________________________________
(page generated 2024-07-16 23:00 UTC)