8 ms·

The Power and Paradox of Bad Software

77 points by headalgorithm 6y ago

hvs 6y ago
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.)
- Koffiepoeder 6y ago
  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.
  - jeffreygoesto 6y ago
    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. I can wholeheartedly second your last paragraph!
  - cmroanirgo 6y ago
    > This sounds like excuse making to me 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.
  - bpyne 6y ago
    "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.
aaaxyz 6y ago
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.
- brabel 6y ago
  > It doesn't need a shiny interface ... Did you ask the users of the system or you just assume they don't want one?
  - DoingIsLearning 6y ago
    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'.
    - brabel 6y ago
      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.
paulryanrogers 6y ago
> 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.
juancn 6y ago
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.
- loopz 6y ago
  Yeah, all those pesky domains standing in the way of great CRUD software! All we want is to pass and transform stringers damnit.
- ximm 6y ago
  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.
  - juancn 6y ago
    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).
- onion2k 6y ago
  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. Lots of people wear more than one hat.
mandada 6y ago
“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?
- jes5199 6y ago
  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
a_c 6y ago
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
- TeMPOraL 6y ago
  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.
mdekkers 6y ago
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.
- BadInformatics 6y ago
  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. [1] https://news.ycombinator.com/item?id=18735023 https://news.ycombinator.com/item?id=18735023
djrobstep 6y ago
> 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.
robocat 6y ago
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?
PeterStuer 6y ago
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.
ComodoHacker 6y ago
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.
oxymoran 6y ago
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.
- nicoburns 6y ago
  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.
  - oxymoran 6y ago
    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.
ilaksh 6y ago
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.
Ithildin 6y ago
"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.
- vsareto 6y ago
  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.
  - Tsarbomb 6y ago
    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.
- 908B64B197 6y ago
  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.
Nevermark 6y ago
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.

77 points by headalgorithm 6y ago

hvs 6y ago

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

Koffiepoeder 6y ago
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.
- jeffreygoesto 6y ago
  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. I can wholeheartedly second your last paragraph!
- cmroanirgo 6y ago
  > This sounds like excuse making to me 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.
- bpyne 6y ago
  "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.

aaaxyz 6y ago

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.

brabel 6y ago
> It doesn't need a shiny interface ... Did you ask the users of the system or you just assume they don't want one?
- DoingIsLearning 6y ago
  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'.
  - brabel 6y ago
    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.

paulryanrogers 6y ago

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

juancn 6y ago

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.

loopz 6y ago
Yeah, all those pesky domains standing in the way of great CRUD software! All we want is to pass and transform stringers damnit.
ximm 6y ago
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.
- juancn 6y ago
  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).
onion2k 6y ago
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. Lots of people wear more than one hat.

mandada 6y ago

“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?

jes5199 6y ago
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

a_c 6y ago

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

TeMPOraL 6y ago
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.

mdekkers 6y ago

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.

BadInformatics 6y ago
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. [1] https://news.ycombinator.com/item?id=18735023 https://news.ycombinator.com/item?id=18735023

djrobstep 6y ago

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

robocat 6y ago

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?

PeterStuer 6y ago

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.

ComodoHacker 6y ago

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.

oxymoran 6y ago

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.

nicoburns 6y ago
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.
- oxymoran 6y ago
  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.

ilaksh 6y ago

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.

Ithildin 6y ago

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

vsareto 6y ago
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.
- Tsarbomb 6y ago
  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.
908B64B197 6y ago
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.

Nevermark 6y ago

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.