Your right, as are your examples, but I want to point out an interesting thing about your examples :)
> - CT and MRI data processing
> - scheduling systems for universities and other schools (makes education more scalable)
Those two read as if they are of different urgency (#1: whoever needs it urgently is at risk of dying, schedules for "non-urgent" cases will be affected for months, turning many into urgent cases; #2: the education systems will suffer, but it only gets dire after multiple days), until you realize that #2 also applies to e.g. hospitals.
Medicine at scale is already barely scraping by as it is (see: overworked staff etc. etc.), but disrupt the internal IT working of hospitals and the indirect body count will rise fast.
> I've come up with a set of rules that describe our reactions to technologies: Anything that is in the world when you're born is normal and ordinary and is just a natural part of the way the world works. Anything that's invented between when you're fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it. Anything invented after you're thirty-five is against the natural order of things.
In fact, I'd go so far as to say that classes not being final or sealed (C#) by default is another failure to set sensible defaults, akin to "everything is mutable unless explicitly marked const".
Properly designing classes for inheritance takes proactive care and is, in my experience, almost never done unless the author has been forced to by external forces (through APIs or agreements with other developers).
For various people, some of that flipped back, and they now record voice messages to send them through e.g. WhatsApp.
My percieved explanation for this is that most of them can't be bothered to type a message but are still very happy to waste the recipient's time. Yes, I'm not thrilled about it.
OTOH, at least these messages are still more asynchronous and less interrupting than a phone call. But the inability to skim them still bothers me to no end.
You write "wherever possible", but: Have you ever seen the beancounting itself having been under scrutiny?
I'd wager a big part of it is also the same politics based asymmetry that's visible everywhere; like nobody ever got fired for buying IBM or people only get credit for managing a crisis, not preventing it in the first place.
If I can add to that: A precursor to both of those would be the precision lathe, from which eventually two of the most crucial prerequisites for the industrialization stem: The ability to a) produce machine parts with a high degree of precision catered for their purpose and/or context, and b) the ability to develop widely established norms these parts can adhere to (or, if you will, by which they could be judged).
The steam engine wouldn't have had its impact without the possibility for e.g. precision engineered pistons, and any industrialization would have been severely impaired without the possibilities that the distributed production of exchangeable parts (even as simple as screws, nuts and bolts) to established norms came with.
Came here to comment on Gothic, too. I'd have picked the original Gothic even more as an example, though -- there, you are in a prisoner colony, even if you are in a settlement. Anger the wrong people and you won't survive the experience for most of the game.
Also the swamp camp is really close to some rather deadly creatures if you're not careful in the early game.
Even worse, some people seemingly aren't even able to produce a question.
"I tried to $ACTION and $FUNCTION throws an error." Followed by awkward silence (or the written equivalent in chat rooms).
Great, why are you telling you me/us about it? What do you expect from me/us? If you're not even willing to produce some text with a question mark at the end, why should anyone bother to invest their time in helping you out?
It might not be the OS, but just statistical inevitability. If you're talking about CPU utilization on Linux, for example, it's not all that unlikely that the number you're staring at isn't "time spent by CPU doing things" but "average CPU run queue length". "100%" then doesn't only mean the CPU gets no rest, but "there's always someone waiting for a CPU to become free". It likely pays off to understand where the load numbers in your tooling actually come from.
Even if that weren't the case, lead times for tasks will always increase with more utilization; see e.g. [1]: If you push a system from 80% to 95% utilization, you have to expect a ~4.75x increase in lead time for each task _on average_: (0.95/0.05) / (0.8/0.2)
Note that all except the term containing ρ in the formula are defined by your system/software/clientele, so you can drop them for a purely relative comparison.
Edit: Or, to try to picture the issue more intuitively: If you're on a highway nearing 100% utilization, you're likely standing in a traffic jam. And if that's not (yet) strictly the case, the probabilty of a small hiccup creating one increases exponentially.
All well and true if all you have to do is process the data programmatically.
And yet, as I said, if the same thinking gets applied to e.g. a store of JSON documents (like ELK), chances are good the thing will ruin the UX for countless people who have to deal with the result. Note that you need exactly no hash maps to store the JSON as it is text.
To expand your analogy: …and yet roads are built so that you can drive your regular car or a box car over them, depending on your use case. You make the choice. A JSON library that doesn't afford such choices (and isn't hyper focused on performance) isn't a good one in my book.
Edit: As a sidenote: Or do you mean a freight train wagon? Then replace "road" with "rails" and "car" with "draisine" :)
> - CT and MRI data processing
> - scheduling systems for universities and other schools (makes education more scalable)
Those two read as if they are of different urgency (#1: whoever needs it urgently is at risk of dying, schedules for "non-urgent" cases will be affected for months, turning many into urgent cases; #2: the education systems will suffer, but it only gets dire after multiple days), until you realize that #2 also applies to e.g. hospitals.
Medicine at scale is already barely scraping by as it is (see: overworked staff etc. etc.), but disrupt the internal IT working of hospitals and the indirect body count will rise fast.