The author doesn't have a strong grasp of what software takes to create nor the regulatory hurdles that are put in place to get software into the healthcare industry, but there's a kernel of truth here. Software developers (and software development companies) understand their problem space _intimately_ and they are the best suited to solve it. Every other field requires additional domain knowledge besides software development knowledge.
This is also why the best way to increase your value as a software developer is not to learn new technologies but to increase your domain knowledge of specific industries. Good developers are problem solvers not "coders".
(Of course you still have to learn new technologies constantly as well. That's unfortunately the nature of the industry.)
This sounds like excuse making to me. In the past few years I've noticed that in order to get a good product one of the most important things is just to say "no, but" to your client. Many software teams just do whatever the client wants without challenging their ideas and beliefs - after all the client knows best. Well, the client knows his business best, but sure as hell they do not know how to make software best.
Out of experience I have noticed that a good great deal of managing my projects is just educating the client and giving them advice. This ranges from technical advice to UX/UI advice to concerns about software quality attributes like maintainability, verifiabilty, integrity, reliability,... You get the picture.
If you manage to keep this communication line open, I've noticed that it is indeed possible to make great products. But it does require courage, independance, ideation from your side and careful communication.
What worked well for me so far is asking "why" and "what do you want to achieve" (in the business domain, not technically), almost until it hurts, taking the client by the hand and walking slowly backwards together until we have a common understanding of what the real task is. Many times it was buried under layers of semi well thought out "solutions". The hard part is building trust that you really want to solve the problen together and not let the client lose face.
Isn't it better to have knowledge of what your clients are talking about? Having written for diverse groups: games to finance to embedded, it's always best to know the direction your client wants to go.
A good developer knows how to deliver product that works for the client, rather than swamping them in technical minutae. Knowing the business properly, you can get them excited about opportunities that arise as a result of knowing their domain enough to give them a competitive edge.
They will love you, your product, and be happy to come back for other projects.
"Well, the client knows his business best, but sure as hell they do not know how to make software best."
My "clients" are all internal. As I work with more departments, I realize how little they know how they operate. They understand well what their mission is. But the processes and exceptions are largely in the minds of one or two people.
My team modernizes legacy integrations between core systems. The departments had a lot of retirements. The retirees took the knowledge with them and left sparse documentation. As I go, I'm trying to develop business requirements documents for them. But it slows down projects.
So, I'd say you're right that clients know what they do but not always how they're doing it. I have a feeling that it's not just my organization experiencing this issue.
I agree with the subtitle, there's a lot of bad and deprecated software in the medical industry. The comparison between climate modeling using Fortran and shiny IDEs with easy to use interfaces is completely wrong though.
Climate modeling, like most compute intensive fields, uses Fortran because it's fast and that's what the software needs to be. It doesn't need a shiny interface because all its meant to do is take in a set of numbers and produce another set of numbers as efficiently as possible. There's is no need for a front-end or for user interactions.
It's like saying that a road bike is "bad" because it isn't as comfortable as your city bike. Different beasts for different needs.
Arguably 'the user' in this case is a highly parallelized multi-core server. :)
The author is looking at it from an 'everything is an App' world, without the domain knowledge of Meteorology or HPC calculations. Implying that a lack of 'user interference' equalls 'bad software' is a very uninformed claim.
Equally misplaced outrage with trying to compare VSCode, from a company with 143 billion in revenue, with (often decade old) EHR systems which are decided 'on a budget' by Heads of clinical departments (AND Purchasing/Finance) with little to no input from actual 'end users'.
Some of these fairly unknown systems that are "terrible" enterprisey make many billions of dollars in sales, VS Code makes nothing directly as it's free (MS gets good PR for publishing it, but it's extremely hard to put a number on how much it's worth for them). Implying that just because MS makes VSC and it makes 143 billion in revenue, it must be much better/nicer than EHR/ systems made by somewhat smaller companies (still, some pretty huge ones make shitty software, like SAP with over 50-billion income) whose whole income come from such system sales is quite irrational of your part.
The user is me, and you put a layer in between me and the mathematics that I need to verify when you prise the Fortran source from my cold dead hands :-).
You better hopw that they are programmers. Meteorologists provide the algos and calculations, programmers (or if you prefer, scientists programmers) then implement it. Scientists focused on science don't have the time to learn good code skills (that's a fact) as there are too many maths and knowledge already in their fields. would not be better if they focus on the science itself?
>Climate modeling, like most compute intensive fields, uses Fortran because it's fast and that's what the software needs to be.
Also because the laws of physics (and the math to do approximation) don't change very often. The older that Runge-Kutta function is in the codebase, the more chance it has to be part of the sample code that they test the compiler's optimizer/benchmark with too!
And Fortran is old enough it's possible to build wrappers around it, should the user really need a new interface.
> So the software people get amazing tools that let them build amazing apps, and the climate people get lots of Fortran.
My guess is this is because of priorities and low hanging fruit. Our economy hasn't priced in climate change but does follow easy money just like the lazy path making rivers crooked. (Ad and gadget money being easier than preserving a habitable world in the face of distant and abstract threats.)
Fortran also has some historical momentum in science.
I would be surprised if we didn’t get great software for making software. We have the domain knowledge.
Software engineers are not meteorologist nor doctors. We don’t want to know or understand meteorology or whatever doctors do, we like software (i.e. the problem solving).
HIPPA, atmospheric models, etc. are not why engineers get into it. So it takes effort to learn enough of a domain to build software for it.
It’s so hard and annoying to do that we even invented entire disciplines to be better at it: Scrum, Domain Driven Design, etc.
We do that for money because we find those domains incredibly boring or we just don’t want to spend the time learning about them.
Building good domain specific software requires a lot of domain specific knowledge.
The inverse is also true though: We not only have the domain knowledge it takes to build software for ourselves, we also have the domain knowledge to use that software to its full potential.
Meteorologist do not have the deep knowledge to apply software effectively. I know we should strive for software that is usable for everyone. But in reality I believe this is a huge factor.
I am not saying that meteorologist (or any other non-programmers) are to blame for that. But I believe we have to acknowledge that fact to be able to overcome it.
That's a very good point. We also make the most of the software we use (even crappy one) because we can usually see the thought process behind it (even if it's misguided and twisted).
Software engineers are not meteorologist nor doctors.
Why not? People can be more than one thing. Heck, you're posting on HN. Are you really saying people can't be a software engineer and a salesperson? Or a software engineer and a CEO? Or a software engineer and a business analyst? You have to be those things to launch a tech startup.
Software failures can, and do, cost lives. If you believe the worst thing that can happen as a software engineer is that you might lose a company some money then you are very, very wrong.
I mostly worked with safety-critical software on avionics and lately with software on medical device so I hope I do understand.
Rather than downplaying the role of software, my point was on pointing out that meteorologists and medical doctors are specialist roles requiring years of focused training. These aren't one of many hats that can be worn by a generalist.
my point was on pointing out that meteorologists and medical doctors are specialist roles requiring years of focused training
Yes, and my point is that there are plenty of doctors and probably most meterologists who write code as part of their jobs. Meterology is statistical modelling at heart, and that requires lots of code. Don't forget that we get soemthing like 40 years of our careers; there's plenty of time to become an expert in a field and then to learn how to write code to build tools to do it better.
Those are indeed specialist roles, but nothing is stopping a potential doctor from taking software engineering in undergrad, or from keeping up with the field while working through med school.
A "dev-ops full-stack developer" is a master of what used to be multiple specializations a few years ago.
Apparently, these days it is not enough to be a database expert, software developer, web designer, and system administrator... you should also be a doctor and a meteorologist.
And don't forget to keep updating your Github open-source portfolio in your free time, because you are going to need it at your next interview.
“That whole Xerox PARC thing in the 1970s—the thing that supposedly gave us the Mac, etc.—was actually not about having a mouse and windows; the big core idea was that we'd build models of our world in software and adapt them as we explored. Doctors could simulate new treatments; children could simulate rocket ships. We'd all have highly visual pocket climate models we could explore and manipulate, or the doctors would all be programmers themselves and make better patient-management systems. The idea was for software to become the humble servant of every other discipline; no one anticipated that the tech industry would become a global god-king among the industries, expecting every other field to transform itself in tech's image.”
A different way of interpreting the article is not why we (computer programmers) haven’t made things better for other people and their industries but why we haven’t found better abstractions for computing itself so that they don’t need us to make the software they need.
We no longer have physical human elevator operators pushing buttons for us because we made an friendly abstraction over that anybody could use. So why does the job of a software developer even exist? Why can’t people productively and easily make their own software? It would likely be better: extremely customized to their own needs, highly tuned based on their own in-depth domain knowledge, and continuously updated since they don’t have to ask and wait for someone else to do it for them. Why do we still have human operators pushing buttons for people?
it’s not just that our tools are poorly suited for non-programmers, they’re barely even suitable for experts! Today I lost 8 hours trying to get XCode to build our app after a library update. Last week I lost 8 hours wrestling with a build server, 8 more hours trying to test changes to some untestable legacy code, and another 8 hours just trying to get our code to do the things it looked like it was obviously written to do. I’m on a team of 4, and if it’s going like that for all of us, simple features like “send an email when <event>“ happens end up costing thousands of dollars to develop.
No wonder our industry is skewed to only solving low-complexity problems in domains that move lots of money!
I have, recreationally, written code to simulate a rocket ship. It was a pretty significantly different experience than my day job. My usual tools didn’t help much, but you don’t actually need a lot of data modeling or fancy UI to draw a trajectory. Debugging was awful, though.
Maybe it’s a good time to re-read Brett Victor’s “Inventing on Principle” and ask ourselves what we can do to get closer to that vision
I think the question "why do software engineers even exist?" can be reframed to ask "what would an end-user programming environment that gives everyone the power of a software engineer look like?"
There are already a few decent task-specific programming environments that let end-users create valuable "software" — the most obvious example being spreadsheets for anything finance-related — however we're still a long ways away from programmers being replaced entirely.
Software engineers are pretty much the modern day scribes. We're literate in programming languages, while the rest of the population is illiterate. We're the only proxy for communicating with computers. So, how do we get the remaining 99% of the population to become literate?
I'm not sure the analogy of the scribe works or that the population needs to be come "literate" in programming languages. You can essentially substitute any profession and the analogy holds true. For example, doctors are literate in medicine, while I am not. Do I need to become literate in medicine (beyond a surface level)? No, this is why professionals exist in the first place, so that I do not need to become "literate" in everything.
No, the analogy still stands in my opinion - medicine is not "eating the world". It has only very narrow application (very important but still narrow) and software can literally change everything in our lifes (if for the better that's up for discussion). So seeing every one else as illiterate sounds lot better than saying that we need better alphabet.
> Why can’t people productively and easily make their own software?
The problem is that software does not understand tacit knowledge, only explicit knowledge. Many people are good at things on an intuitive level, but aren't able to explain clearly and unambiguously and comprehensively why they do those things. Structuring thoughts and processes like this is an important (and quite rare) skill in itself.
Secondly, "tech" is not a completely homogenous or bland medium, certain things are simply much easier to do than others. It's much easier for humans to drive cars, even with an error rate, than for computers. While it's much easier for computers to do arithmetic. The implication of this is that it's often much better to change your process - or possibly replace your entire business - than to take the current one and freeze it into a computer.
That's the problem with a lot of bureaucratic efforts. Often the "process" doesn't actually work as written down, and relies on a lot of slack and human judgement by individual low-status people who aren't included in the software development process. So freezing the process in software, even if done exactly to spec, doesn't work.
See also "Seeing like a State"; the process of making people and processes 'legible' to a bureaucratic system changes them, as does computerising them.
Third related problem is demarcation: even if individuals want to automate their workflow, they're still part of an organisation which would prefer they stay in their lane. So many "enterprise" disasters are the result of the people making the purchasing decision refusing to work with the actual users.
This is a harder problem then it seems. Lots of applications are built to be programming for non-programmers and the company I work for loves the idea and falls for it all too often. In reality what happens are the users still can't or won't learn how to translate their own work processes into a logic required by the application regardless of how "intuitive" the interface is and the system ends up in the hands of software devs that now have to use a tool with significantly less flexibility and more bloat.
In other words, there are elevator buttons out there but people don't know what floor they need to go to.
Software is both a standalone industry and a skillset embedded within all industry. It is like management. Yes there are professional managers, consulting companies and the like. But you can't have good management by hiring professional managers. You have good management by becoming professional managers, assuming you already know you domain well. That's why an MBA on its own is useless, unless one is to enter consulting
I would say the same applies to software development
I'd say it doesn't, because specializing in pure software is still useful for building better tools to make software. Does MBA help managers develop better management paradigms? I don't know. But if yes, then the mistake is hiring MBAs for managing company, instead of treating it as research skillset.
There are amazing software options for doctors and climatologists and all manner of folks that have to use software.
Often though, someone isn’t willing to pay for top shelf quality so the cheapest option that is viable is chosen. Hence doctors end up with crappy options.
I have yet to see a "good" EHR. The top dollar solutions are at best usability nightmares[1] and since every major vendor is based out of the US, they all optimize for billing/CYA over reducing clinician workload or increasing the standard of care.
Do healthcare organizations cheap out on critical software components or modifications? Absolutely, all the time. Do they also spend exorbitant amounts on these bad-for-everyone-but-administrator systems? Also yes. I agree with the point many folks have made about targeting the right audience: just consulting the C-suite is a surefire way to create software end users will hate.
> when I open these tools I feel like a medieval stonemason dragged into midtown Manhattan and left to stare at the skyscrapers. My mouth hangs open and my chisel falls from my sandstone-roughened hands.
I have the exact opposite reaction - I see software out in the world and wonder how any of it works at all with the garbage tools we have for creating it.
Software developers also modify everything to suit their tools: languages, processes, frameworks, legal structures, business structures, etcetera.
Anyone involved with the frontier of software is generally proactive towards change because the ability to make wholesale changes is one of the reasons for people to choose software as a discipline.
In other domains the software is expected to mold to an existing domain, and often the domain is resistant to any change (legal, medical, etcetera).
Edit: and where do astonishingly good software products produced for consumers fit into this argument?
No, not all "software for software developers" is all that great.
What I have seen over the years is that the worst software is that in which the end user has little decision power. Your typical ERP sold to the CxO and configured under the auspices of some business analysts that have never and will never perform the job that the poor end users are supposed to accomplish using it is the worst.
To me, the answer is simple: money goes where it yields most return. Applied to software, money goes to apps and experiences that can be scaled to millions and billions of users. Games, social networks, e-commence, etc. Who would invest big money in a product to automate some industry with 10K people working in it?
For big enterprise vendors is's slightly different. Where our next year budget goes? We have basically two options: a) improve the product and charge more, and b) invest in marketing and acquire new customers. Of course b) wins as long as there are plenty of new customers to win.
Every piece of enterprise software I have used is frustratingly bad and cumbersome. I have determined that the problem is because enterprise software is not written by the end user, whereas say, a smartphone operating system is inherently written by an end user. It’s not enough for the designer of software to have knowledge of the end use, they actually need to be a user to get it right.
I think it's more because it's not the end user buying the software, and the people that do don't choose the software that's best for the end user. I've worked on enterprise software and often there are lots of end-user feature improvements that we'd like to work on but get deprioritised because that's not what will allow us to sell the software.
Yea you are right, purchasing software would present different challenges because you would have different types of users.
My frame of reference was for companies that design their own in-house software but it still sucks. I work at a large insurance company and our claim software was designed in-house and it is just the worst thing ever. Same experience when I worked at a large rental car company.
Well, actually, there might be something about Fortran that makes it harder to maintain than other new programming languages. I don't know but it would have been interested to hear such details in this article.
I believe if there is a lot of math in a simulation codebase that can't easily be verified and you aren't sure if it's all necessary, then you should not assume that the simulation is correct. So there is where I think the instinct to modernize could lead to objectively better software.
The math that needs to be verified and might need to be changed should be easy to find and change and verify. To improve the feedback loop, having an interactive visualization may be objectively much better than a batch job that requires a long wait and another program to create a graph.
So I don't know the actual program, but it's quite possible that you would be able to more effectively predict the weather if you changed it completely to work like this:
1. Pull out the core equations and put them in a UI (not necessarily editable structurally).
2. Add an option to select different equations/modeling strategies. Show the equations prominently.
3. Make the parameters for the equations show up in the UI.
4. Convert the system to use CUDA or OpenCL and get them a brand new Nvidia 3090 or something.
So now they have an interactive parallelized fast simulation where the equations/strategies and parameters used are prominently displayed.
I think the objection is going to be that now it's harder to change the equations. And if they really change the equations a lot then that is a valid argument. If they change the equations once every ten or twenty years, or just forget about the old ones and ignore their effects while piling on more equations, then that argument doesn't necessarily hold water.
"The software industry makes amazing tools for itself, while doctors and scientists are stuck with old code. Tech needs to quit hacking and start listening."
Then pay for better software? Take your money elsewhere? I don't understand what we're supposed to do here. I get it, your industry has old software. Maybe hire us to make it better? Not my problem you're still using Windows XP and Fortran though. Sounds to me like corners were cut and budgets were not set appropriately.
Pay isn't the issue for hospitals buying software, they are already paying big money to vendors. And they often can't take their money elsewhere because of contracts. I heard 10 years lock-in for an EHR solution.
Lots of software churn is probably bad for medical workers too if they are constantly retraining in high stress environments - they might be technical but may not be comfortable with computers.
Building your own software is do-able for some aspects (to avoid paying millions for a simple web app), but most hospitals are not going to want to build their own EHR software or other large pieces.
While not EHRs, I have experience working in the EMR field, and it absolutely was a race to the bottom, vendors undercutting each other, and physicians being surprised that the cheapest vendor or product they went with turned out to be total trash.
There's a lot of money in the medical industry (private or public) but it seems that everywhere and everyone is constantly getting their budget slashed. Yet the amount of money that's poured into this industry keeps balooning!
I have this rule that any organization that treats software as a cost center will systematically get bad software AND overpay for it. Because by under-funding (with compensation, tittle and power in the organization) engineering they end-up pushing talent elsewhere, mostly to organizations where tech is considered a profit center.
Software, it seems, is treated as a cost center by the medical industry and by a lot of research labs (things like not granting authorship to software contributors).
The tone of the article is rather typical of the medical industry. Very condescending to say the least.
Most meteorologists probably use the climate data produced, not the program that produced the data. So the data producing program’s natural interface is simply the command to run it and the file system for storing results.
The separation between simple interface for launching a big calculation vs. friendly software for using the results is sensible and common in at least two cases.
1. The data is calculated infrequently using lots of computing power & time. After which it is the data that is primarily used.
2. The data is calculated by one group. Many other groups just use the produced data.
In climate calculations, I expect both cases apply.
55 comments
[ 2.9 ms ] story [ 106 ms ] threadThis is also why the best way to increase your value as a software developer is not to learn new technologies but to increase your domain knowledge of specific industries. Good developers are problem solvers not "coders".
(Of course you still have to learn new technologies constantly as well. That's unfortunately the nature of the industry.)
Out of experience I have noticed that a good great deal of managing my projects is just educating the client and giving them advice. This ranges from technical advice to UX/UI advice to concerns about software quality attributes like maintainability, verifiabilty, integrity, reliability,... You get the picture.
If you manage to keep this communication line open, I've noticed that it is indeed possible to make great products. But it does require courage, independance, ideation from your side and careful communication.
I can wholeheartedly second your last paragraph!
Isn't it better to have knowledge of what your clients are talking about? Having written for diverse groups: games to finance to embedded, it's always best to know the direction your client wants to go.
A good developer knows how to deliver product that works for the client, rather than swamping them in technical minutae. Knowing the business properly, you can get them excited about opportunities that arise as a result of knowing their domain enough to give them a competitive edge. They will love you, your product, and be happy to come back for other projects.
My "clients" are all internal. As I work with more departments, I realize how little they know how they operate. They understand well what their mission is. But the processes and exceptions are largely in the minds of one or two people.
My team modernizes legacy integrations between core systems. The departments had a lot of retirements. The retirees took the knowledge with them and left sparse documentation. As I go, I'm trying to develop business requirements documents for them. But it slows down projects.
So, I'd say you're right that clients know what they do but not always how they're doing it. I have a feeling that it's not just my organization experiencing this issue.
It's like saying that a road bike is "bad" because it isn't as comfortable as your city bike. Different beasts for different needs.
Did you ask the users of the system or you just assume they don't want one?
The author is looking at it from an 'everything is an App' world, without the domain knowledge of Meteorology or HPC calculations. Implying that a lack of 'user interference' equalls 'bad software' is a very uninformed claim.
Equally misplaced outrage with trying to compare VSCode, from a company with 143 billion in revenue, with (often decade old) EHR systems which are decided 'on a budget' by Heads of clinical departments (AND Purchasing/Finance) with little to no input from actual 'end users'.
I'm pretty sure the "users" of the system are mostly programmers who write batch jobs.
Also because the laws of physics (and the math to do approximation) don't change very often. The older that Runge-Kutta function is in the codebase, the more chance it has to be part of the sample code that they test the compiler's optimizer/benchmark with too!
And Fortran is old enough it's possible to build wrappers around it, should the user really need a new interface.
My guess is this is because of priorities and low hanging fruit. Our economy hasn't priced in climate change but does follow easy money just like the lazy path making rivers crooked. (Ad and gadget money being easier than preserving a habitable world in the face of distant and abstract threats.)
Fortran also has some historical momentum in science.
Software engineers are not meteorologist nor doctors. We don’t want to know or understand meteorology or whatever doctors do, we like software (i.e. the problem solving).
HIPPA, atmospheric models, etc. are not why engineers get into it. So it takes effort to learn enough of a domain to build software for it.
It’s so hard and annoying to do that we even invented entire disciplines to be better at it: Scrum, Domain Driven Design, etc.
We do that for money because we find those domains incredibly boring or we just don’t want to spend the time learning about them.
Building good domain specific software requires a lot of domain specific knowledge.
Meteorologist do not have the deep knowledge to apply software effectively. I know we should strive for software that is usable for everyone. But in reality I believe this is a huge factor.
I am not saying that meteorologist (or any other non-programmers) are to blame for that. But I believe we have to acknowledge that fact to be able to overcome it.
Why not? People can be more than one thing. Heck, you're posting on HN. Are you really saying people can't be a software engineer and a salesperson? Or a software engineer and a CEO? Or a software engineer and a business analyst? You have to be those things to launch a tech startup.
Lots of people wear more than one hat.
On one hand you have professions and roles where failures are measured in lost revenue versus another where failures are measured in lost lives.
Rather than downplaying the role of software, my point was on pointing out that meteorologists and medical doctors are specialist roles requiring years of focused training. These aren't one of many hats that can be worn by a generalist.
Yes, and my point is that there are plenty of doctors and probably most meterologists who write code as part of their jobs. Meterology is statistical modelling at heart, and that requires lots of code. Don't forget that we get soemthing like 40 years of our careers; there's plenty of time to become an expert in a field and then to learn how to write code to build tools to do it better.
I had a teammate who did the later.
I work with very good software engineers that were originally mathematicians, physicists, linguists, electronic engineers among others.
But once they become software engineers, they kind of are just that. It tends to dominate all thought processes.
It's not that they don't leverage their background, but software tends to eat the world.
Apparently, these days it is not enough to be a database expert, software developer, web designer, and system administrator... you should also be a doctor and a meteorologist.
And don't forget to keep updating your Github open-source portfolio in your free time, because you are going to need it at your next interview.
A different way of interpreting the article is not why we (computer programmers) haven’t made things better for other people and their industries but why we haven’t found better abstractions for computing itself so that they don’t need us to make the software they need.
We no longer have physical human elevator operators pushing buttons for us because we made an friendly abstraction over that anybody could use. So why does the job of a software developer even exist? Why can’t people productively and easily make their own software? It would likely be better: extremely customized to their own needs, highly tuned based on their own in-depth domain knowledge, and continuously updated since they don’t have to ask and wait for someone else to do it for them. Why do we still have human operators pushing buttons for people?
I have, recreationally, written code to simulate a rocket ship. It was a pretty significantly different experience than my day job. My usual tools didn’t help much, but you don’t actually need a lot of data modeling or fancy UI to draw a trajectory. Debugging was awful, though.
Maybe it’s a good time to re-read Brett Victor’s “Inventing on Principle” and ask ourselves what we can do to get closer to that vision
There are already a few decent task-specific programming environments that let end-users create valuable "software" — the most obvious example being spreadsheets for anything finance-related — however we're still a long ways away from programmers being replaced entirely.
Software engineers are pretty much the modern day scribes. We're literate in programming languages, while the rest of the population is illiterate. We're the only proxy for communicating with computers. So, how do we get the remaining 99% of the population to become literate?
The problem is that software does not understand tacit knowledge, only explicit knowledge. Many people are good at things on an intuitive level, but aren't able to explain clearly and unambiguously and comprehensively why they do those things. Structuring thoughts and processes like this is an important (and quite rare) skill in itself.
Secondly, "tech" is not a completely homogenous or bland medium, certain things are simply much easier to do than others. It's much easier for humans to drive cars, even with an error rate, than for computers. While it's much easier for computers to do arithmetic. The implication of this is that it's often much better to change your process - or possibly replace your entire business - than to take the current one and freeze it into a computer.
That's the problem with a lot of bureaucratic efforts. Often the "process" doesn't actually work as written down, and relies on a lot of slack and human judgement by individual low-status people who aren't included in the software development process. So freezing the process in software, even if done exactly to spec, doesn't work.
See also "Seeing like a State"; the process of making people and processes 'legible' to a bureaucratic system changes them, as does computerising them.
Third related problem is demarcation: even if individuals want to automate their workflow, they're still part of an organisation which would prefer they stay in their lane. So many "enterprise" disasters are the result of the people making the purchasing decision refusing to work with the actual users.
start by asking them to draw a bicycle
In other words, there are elevator buttons out there but people don't know what floor they need to go to.
I would say the same applies to software development
Often though, someone isn’t willing to pay for top shelf quality so the cheapest option that is viable is chosen. Hence doctors end up with crappy options.
Do healthcare organizations cheap out on critical software components or modifications? Absolutely, all the time. Do they also spend exorbitant amounts on these bad-for-everyone-but-administrator systems? Also yes. I agree with the point many folks have made about targeting the right audience: just consulting the C-suite is a surefire way to create software end users will hate.
[1] https://news.ycombinator.com/item?id=18735023
I have the exact opposite reaction - I see software out in the world and wonder how any of it works at all with the garbage tools we have for creating it.
Anyone involved with the frontier of software is generally proactive towards change because the ability to make wholesale changes is one of the reasons for people to choose software as a discipline.
In other domains the software is expected to mold to an existing domain, and often the domain is resistant to any change (legal, medical, etcetera).
Edit: and where do astonishingly good software products produced for consumers fit into this argument?
What I have seen over the years is that the worst software is that in which the end user has little decision power. Your typical ERP sold to the CxO and configured under the auspices of some business analysts that have never and will never perform the job that the poor end users are supposed to accomplish using it is the worst.
For big enterprise vendors is's slightly different. Where our next year budget goes? We have basically two options: a) improve the product and charge more, and b) invest in marketing and acquire new customers. Of course b) wins as long as there are plenty of new customers to win.
My frame of reference was for companies that design their own in-house software but it still sucks. I work at a large insurance company and our claim software was designed in-house and it is just the worst thing ever. Same experience when I worked at a large rental car company.
I believe if there is a lot of math in a simulation codebase that can't easily be verified and you aren't sure if it's all necessary, then you should not assume that the simulation is correct. So there is where I think the instinct to modernize could lead to objectively better software.
The math that needs to be verified and might need to be changed should be easy to find and change and verify. To improve the feedback loop, having an interactive visualization may be objectively much better than a batch job that requires a long wait and another program to create a graph.
So I don't know the actual program, but it's quite possible that you would be able to more effectively predict the weather if you changed it completely to work like this:
1. Pull out the core equations and put them in a UI (not necessarily editable structurally).
2. Add an option to select different equations/modeling strategies. Show the equations prominently.
3. Make the parameters for the equations show up in the UI.
4. Convert the system to use CUDA or OpenCL and get them a brand new Nvidia 3090 or something.
So now they have an interactive parallelized fast simulation where the equations/strategies and parameters used are prominently displayed.
I think the objection is going to be that now it's harder to change the equations. And if they really change the equations a lot then that is a valid argument. If they change the equations once every ten or twenty years, or just forget about the old ones and ignore their effects while piling on more equations, then that argument doesn't necessarily hold water.
Then pay for better software? Take your money elsewhere? I don't understand what we're supposed to do here. I get it, your industry has old software. Maybe hire us to make it better? Not my problem you're still using Windows XP and Fortran though. Sounds to me like corners were cut and budgets were not set appropriately.
Lots of software churn is probably bad for medical workers too if they are constantly retraining in high stress environments - they might be technical but may not be comfortable with computers.
Building your own software is do-able for some aspects (to avoid paying millions for a simple web app), but most hospitals are not going to want to build their own EHR software or other large pieces.
I have this rule that any organization that treats software as a cost center will systematically get bad software AND overpay for it. Because by under-funding (with compensation, tittle and power in the organization) engineering they end-up pushing talent elsewhere, mostly to organizations where tech is considered a profit center.
Software, it seems, is treated as a cost center by the medical industry and by a lot of research labs (things like not granting authorship to software contributors).
The tone of the article is rather typical of the medical industry. Very condescending to say the least.
The separation between simple interface for launching a big calculation vs. friendly software for using the results is sensible and common in at least two cases.
1. The data is calculated infrequently using lots of computing power & time. After which it is the data that is primarily used.
2. The data is calculated by one group. Many other groups just use the produced data.
In climate calculations, I expect both cases apply.