The Power and Paradox of Bad Software
wired.com
wired.com
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.)
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.
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.
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.
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.
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?
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 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.
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.
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.
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.
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.
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.
I would say the same applies to software development