The value of good software extends beyond its cost

It’s commonly joked about that some of the best scientific software looks like it comes from the 1990s. In fact, plenty of academic labs have computers running ancient operating systems because those are the only ones compatible with their software. It’s a practice that’s probably fine, so long as you never connect systems that are too old for security updates to the internet.

A modern pharma company has countless pieces of software – from few-user applications like high-throughput experimentation to platforms every scientist needs, like electronic lab notebooks (ELNs). And that’s not to mention HR, recruiting, finance and procurement. When a business brings in new software, it’s a big deal, or it should be – if not, I’d be concerned that the package might not fit in optimally with the existing workflows and data strategy, ultimately taking more of people’s time than is needed.

While chemists regularly complain about the vast number of different apps and websites they use every day, sometimes there is a good reason. For example, most of us already have good liquid chromatography–mass spectrometry, inventory and complex data visualisation programs. In a large company, there’s no such thing as ‘off the shelf’: any new software must integrate with these existing tools. Thus, rather than providing an ‘all singing, all dancing’ platform for everything, we might end up with yet another app.

Build quality

When we take on something new, the biggest question is whether to buy the software or make something yourself. An advantage of buying vendor software is that you outsource much of the hard work, and the development costs are shared between multiple customers. However, it’s a common complaint that third-party vendors often don’t prioritise integrations with existing tools over adding new functions, frustrating users.

However, these problems don’t go away if you make the software in-house – you just become responsible for all of them! Collaboration is the most important thing, as many scientists understand using but not building software, and most software engineers won’t be experts in chemistry. Any imbalance between these groups means your software will be unhelpful and annoying to use.

My main piece of advice when building your own scientific software is not to assume you know everything best just because you are the end user. Once, I helped software engineers to build a custom ELN, and in several instances the platform was inefficient and clunky because scientific team leads had taken an authoritarian approach. You might think you’ll receive the product you were imagining that way, but it will lack the polished feel of professional software and the benefit of an outsider’s perspective. There are software companies that are used to dealing with chemistry, and as experts in their own field, we scientists need to unite with them to reap the best possible outcome.

Software is generally undervalued in the chemistry community

What becomes clear is that user experience is sovereign. A good integration doesn’t just meet technical requirements. At their best they incorporate our scientific mindsets, workflows and anything that will help us work better and feel more in control while doing so.

When used cleverly, software can quietly reduce silos and streamline workflows, without the users having to work on those as separate, and usually angst-inducing, activities. Tech can also help level the playing field for scientists with disabilities. However, these gains are far from automatic. Somebody is going to have to work hard to make everything appear easy for the chemists.

Searching for structures

A large part of the experience, where it’s relevant, is the chemicals themselves. Organic chemists like to see structures. We intrinsically want to be able to interact with molecules in meaningful ways, which can include substructure search and definitely don’t include scrolling through hundreds of inscrutable, text-based representations of those structures – something I’ve actually seen attempted. If the software doesn’t also understand the myriad of names a single chemical can have, be prepared for it not to work out.

The problem becomes even tougher for metal complexes, which many of the leading chemoinformatic structural representations still cannot handle reliably. And yet organic chemists use metal complexes as catalysts every day, so they need to appear correctly and be searchable almost everywhere simple organic structures are found.

Software is generally undervalued in the chemistry community, and cases where it has been designed or implemented badly probably do not help perceptions. However, the 90s style programs still used today are a testament that when it is done well, the results are long-lasting. At its best, software can save us time, effort, money and materials. At its worst, it causes more problems than we started with. Underestimate it at your peril.