What's Happening?

This week, our class chose and reflected on articles from Software, Computer, or CoACM magazines. While perusing software magazines (finding good ones was an exercise in itself), I stumbled upon a WIRED magazine article titled “The Power and Paradox of Bad Software” by Paul Ford.

The introduction of this article is what caught my attention. It mentions doctors complaining about the hospital’s software and the general prevalence of “bad” software in the medical field. My old neighbor is an anesthesiologist and she shares this disdain for her hospital’s software. Knowing I’m studying computer science, she’s (somewhat jokingly) approached me with the idea of collaborating on the ultimate medical software more than once.

What is it with outdated, unsatisfactory software in fields like medicine, academia, banking, and construction - to name the few that the author does? Well, the author frames this as a bit of a mystery: “The software people get amazing tools that let them build amazing apps, and the climate people get lots of Fortran. This is one of the weirdest puzzles of this industry.”

The bottom line the author puts forward is that “bad” does not necessarily mean inaccurate software. He gives the example of climate change software. When he dug into these models, he found that they are simply hundreds of Fortran files. However, they can attempt to understand the world through programming. They garner a lot of information through that attempt that we use daily to make crucial decisions about our planet - no toggles, buttons, or switches required. Some industry systems like this one are extremely old, making an overhaul difficult. Outside of that, adding any of these features may be an unnecessary expense and complication. This is what distinguishes between “academic programming” to create something in a non-tech industry and “tech industry programming”. The former creates a project that completes the industry tasks best while the latter focuses on best profit and usability.

The author suggests another idea that explains this. It’s quite intuitive: “code begets more code.” For example, IDEs are to software engineering as the software my neighbor dislikes is to the medical field. However, the caliber and user-friendliness of IDEs are beyond comparison. Beyond that, they free while medical software costs hundreds of thousands of dollars. IDEs are also developed by the same people who use them. It seems to me that these facts are what encourage programmers to develop more programs, creating a cycle of great tools within the industry.

In my neighbor’s case, I’m now curious to know what it was about the software she didn’t like. I will follow up with her, but from what I remember, her issues with the medical software are all centered around a lack of user-friendliness. She, as a user, is constantly afraid that she won’t properly record a patient’s stats or submit a chart to the wrong place due to the unintuitive nature of the program. I do not remember her reporting that actual results from the program were inaccurate. They very well could have been spot on, like the results of the antique climate change models the author mentions.

Although my neighbor may not agree, the author suggests that if these kinds of programs aren’t broken, we shouldn’t try to fix them or adjust them to the standards of the tech industry. While I agree with this to an extent, I also believe that if the antiquity of the program leads to a lack of usability, this can become dangerous, particularly in fields where human lives are at stake.

• 2021 11
• 2020 22