The software industry makes amazing software tools for itself, while doctors, academics, and scientists are stuck using bad software
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. Tweets: @terronk , @nxthompson , and @backchnnl Tweets: Lee Edwards / @terronk : Mechanical engineers make fantastic mechanical tools for mechanical tasks - this has probably been true since the first proto-human stuck a handle on an ax-shaped rock. Ever see how the people who made last generation's MCAD software think version control should work? https://twitter.com/... @nxthompson : “Good software makes work easier, but bad software brings us together into a family. I love bad software, which is most of it.” @ftrain https://www.wired.com/... Backchannel / @backchnnl : 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. https://www.wired.com/...
Context & Ripple Effects
This Backchannel essay extends a critique the coverage has been circling for years: experts had already argued that approaches like model-driven engineering could cut software errors by changing how programs are built, and Longreads' piece on tech blaming users instead of fixing unethical design made the adjacent point that the industry designs around its own assumptions. Lee Edwards' tweet about MCAD vendors gives the concrete case — even mechanical engineers, who build superb physical tools, get version control designed by people who have never used it the way engineers do.
What makes the argument land is that the people stuck with the worst software — doctors, academics, scientists — are precisely those with neither the time nor the training to fork the codebase themselves, though later coverage of LLMs as a Gutenberg moment for software creation sketches how that lockout might finally break.
First-order effects
- Domain professionals in medicine, academia, and science stay locked into legacy tools whose interfaces reflect developer convenience rather than clinical or research workflows, while software makers keep shipping polished tools for their own kind — the exact dynamic Edwards illustrates with MCAD version control.
Second-order effects
- Vendors selling into professional markets face pressure to embed user research and listening into design, since the blame-the-user posture Longreads documented becomes commercially untenable when customers have alternatives or public criticism.
Third-order effects
- If AI-assisted development keeps lowering the barrier to building software, domain experts may stop waiting for the software industry and start writing their own tools — dissolving the builder/user split this essay identifies as the root problem, and accelerating software's fade into undifferentiated background infrastructure.
The trend: Software creation is slowly shifting from an engineer-only priesthood toward tools and, eventually, authorship by the domain experts the current industry designs around.