A little under two years ago, I wrote a post titled “Biology software is bad because biologists like bad software.” It may seem like this week’s title is the opposite, claiming biology software is good, actually. But it’s really more of a reframing of the same underlying problem.
Let me explain.
By “biology software” I mean commercial software designed to be used by biology labs and adjacent teams like computational biologists and data scientists at biotech startups. There’s a common perception that all of this software was written decades ago and lacks the kind of user friendly UIs that you find in modern consumer-oriented web apps. Or maybe it isn’t that old, but it was written by folks who either don’t know how to build modern software, or don’t care.
But while there may be one or two prominent examples that fit into this category, there are many many more that are user friendly, reliable and designed around the needs of a modern biotech organization. It just seems like very few of the teams who would benefit from these applications know about them… or where to look for them… or even that they might possibly exist.
It seems that we, as a community, have convinced ourselves that this software isn’t out there. So we don’t look for it. And when we accidentally stumble across it, we assume there’s a catch and that it’s probably actually bad. We don’t trust it so we build our own tools and systems with fewer features and more down time. Then we convince ourselves that this is the right way, in fact the only way, and start our own software startups to build a commercial version because no one else seems to be doing it.
To be clear, I think there’s still plenty of space for software engineers in the space to found startups and build exciting new software. I just want you to do it with open eyes and an objective understanding of what’s already out there.
And look, I’ve been as guilty as anyone else of taking it for granted that there’s no good biology software out there. (I did write that post two years ago, after all.) But since I started writing this newsletter, I’ve heard from so many founders who are building, and have built, amazing software. The software that we, as a community, need to make our organizations more data driven.
So I’m now convinced that the reason biotech teams use bad software, whether it’s home built projects that you don’t have the bandwidth to complete or legacy software that the bench team has used for the last 20 years and swears by, is that they refuse to believe there could be a better way.
Well, it’s time to stop. We need to begin shifting the narrative to be closer to reality: There’s lots of good software out there. We just aren’t good at finding it. More on why we’re bad at finding it next week, but in the mean time, I will point out two sites that have tried to address this: The Life Science Software Landscape by Natalie Ma at Deep Origin and Pylogeny.bio by Nishant Sha at Nitro Bio (with help from the Bits in Bio community.)
I’m also working on a project to create a more detailed picture of biology software using information about the software from the creators themselves. If you’re building software for biology/biotech and want to be involved send me an email at jesse@merelogic.net to learn more.
Thanks for reading this week’s Scaling Biotech! I really appreciate your continued support, and I read every comment and reply.
As a reminder, I offer several services to help connect biotech teams with tools, practices and expertise to make their organizations more data driven.
For Biotech Startups: My Stack Audit will help you create a shared understanding of expectations and gaps around data and metadata.
For Software Startups: Go-to-market consulting to help you find your ideal customers and communicate how you’ll solve their biggest problems.
For IT/Informatics Consultants: White papers and case studies to define and demonstrate your specialized expertise.
For more information about any of these, send me an email at jesse@merelogic.net
I will add, Jesse, that IMO part of the problem is that a) the Venn diagram of tool functionality is...complex... and b) there aren't well-established "stacks" that work well together, and from which some tools could be positioned as alternatives/augments. I think building something like that would be a worthy layer on top of Natalie and Nishant's efforts.