Hacker News Reader

Comment by jawns | Hacker News Reader

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.

View on HN

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

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

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

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.

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

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

> particularly if your userbase often has literally decades worth of muscle memory

My experience from informally inquiries shows that users value fast TUIs regardless of the experience they amounted. Even the young mainframe and (rarer) Clipper users I talk to report preferring these systems over newer, web-based ones.

I worked in the travel industry, and the old TUI was much more efficient at several tasks than any GUI that we could provide.

As developers we should show some sympathy, but some of my co workers didn't see it that way. They complained about the old TUI, while they themselves preferred using a terminal for git and other tools that actually have most of the functionality that they need in a GUI

> As developers we should show some sympathy, but some of my co workers didn't see it that way. They complained about the old TUI, while they themselves preferred using a terminal for git and other tools that actually have most of the functionality that they need in a GUI

At least for git, I prefer a terminal as well. git is easy enough to shoot yourself in the foot when you're using it in a terminal, but git GUIs tend to abstract away so much for anything more complex than "git commit/push/pull" that it's even easier, and way harder to recover from.

I prefer git GUIs. Never used git in a terminal.

> 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

They had that too.

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.

Isn't that what WASAM suppose to be?

> * Users: Sure, use whatever language you want, as long as it runs in my browser, because that's what I'm already using.

I'm not sure I've met a consumer of diagrams who ever really wanted to know what's going on, so much as they wanted to have their pre-conceptions validated for the brief time they're interested in the problem.

I have had too many conversations with managers who want to talk about "pipelines" but then you ask how the system is handling dropped or failed messages and get a deafening silence or "just don't worry about it it's rare".

People love arrows showing the "direction" data is going, but do things like assume that direction means "security" (it doesn't - any channel other then a full on data-diode is 2-way) or implies other operations (i.e. about storage).

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.

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.

Yeah, the PowerPoint-ization is now so complete that people can't even conceive that there are other ways to give a presentation.

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.

The article does indeed argue that we need smarter ways to create diagrams - so that devs don't have to manually create / update them and other teams get the info that they need.

Saving time and effort for devs, while making dynamic visualizations with different levels of detail (i.e. more and less technical for different audiences) is possible.

Reply on news.ycombinator.com