4 ms·

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

by jawns 2y ago

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 2y ago
> * 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 2y ago
  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 2y ago
    > 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/how-to-display-a-list-of-amadeus-interface-records-a.i.r.s- https://servicehub.amadeus.com/c/portal/view-solution/832976...
    - Jtsummers 2y ago
      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 2y ago
        > 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 2y ago
        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 2y ago
    > 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 2y ago
      They had that too.
- jawns 2y ago
  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 2y ago
  Isn't that what WASAM suppose to be?
- TheRealPomax 2y ago
  > * Users: Sure, use whatever language you want, as long as it runs in my browser, because that's what I'm already using.
qznc 2y ago
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 2y ago
  Yeah, the PowerPoint-ization is now so complete that people can't even conceive that there are other ways to give a presentation.
  - maccard 2y ago
    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 2y ago
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.
XorNot 2y ago
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).
argoeris 2y ago
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.

by jawns 2y ago

BadHumans 2y ago

> * 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 2y ago
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 2y ago
  > 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/how-to-display-a-list-of-amadeus-interface-records-a.i.r.s- https://servicehub.amadeus.com/c/portal/view-solution/832976...
  - Jtsummers 2y ago
    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 2y ago
      > 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 2y ago
        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 2y ago
  > 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 2y ago
    They had that too.
jawns 2y ago
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 2y ago
Isn't that what WASAM suppose to be?
TheRealPomax 2y ago
> * Users: Sure, use whatever language you want, as long as it runs in my browser, because that's what I'm already using.

qznc 2y ago

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 2y ago
Yeah, the PowerPoint-ization is now so complete that people can't even conceive that there are other ways to give a presentation.
- maccard 2y ago
  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 2y ago

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.

XorNot 2y ago

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

argoeris 2y ago

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.