El art\u00edculo explora el uso de software cient\u00edfico en la comunidad qu\u00edmica, destacando los desaf\u00edos y las decisiones asociadas. Algunos puntos son resaltados, como por ejemplo, la dependencia de software obsoleto, lo que genera riesgos de seguridad; la presencia de ecosistemas de software complejos en las compa\u00f1\u00edas farmac\u00e9uticas donde el desaf\u00edo es integrar software nuevo en los flujos de trabajo existentes; o el dilema de comprar o desarrollar software, donde comprar software ofrece ventajas como compartir los costos de desarrollo, pero a menudo carece de una integraci\u00f3n fluida, mientras que, desarrollarlo internamente requiere la colaboraci\u00f3n entre cient\u00edficos e ingenieros para evitar ineficiencias y lograr dise\u00f1os intuitivos. El art\u00edculo subraya que un software bien dise\u00f1ado, aunque parezca obsoleto, puede generar beneficios duraderos, mientras que las soluciones mal implementadas suelen generar m\u00e1s problemas de los que resuelven. En definitiva, el software merece mayor reconocimiento y una aplicaci\u00f3n reflexiva en la comunidad qu\u00edmica.<\/p>\n
It\u2019s 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\u2019s a practice that\u2019s probably fine, so long as you never connect systems that are too old for security updates to the internet.<\/p>\n
A modern pharma company has countless pieces of software \u2013 from few-user applications like high-throughput experimentation to platforms every scientist needs, like electronic lab notebooks (ELNs). And that\u2019s not to mention HR, recruiting, finance and procurement. When a business brings in new software, it\u2019s a big deal, or it should be \u2013 if not, I\u2019d be concerned that the package might not fit in optimally with the existing workflows and data strategy, ultimately taking more of people\u2019s time than is needed.<\/p>\n
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\u2013mass spectrometry, inventory and complex data visualisation programs. In a large company, there\u2019s no such thing as \u2018off the shelf\u2019: any new software must integrate with these existing tools. Thus, rather than providing an \u2018all singing, all dancing\u2019 platform for everything, we might end up with yet another app.<\/p>\n
Build quality<\/strong><\/p>\n 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\u2019s a common complaint that third-party vendors often don\u2019t prioritise integrations with existing tools over adding new functions, frustrating users.<\/p>\n However, these problems don\u2019t go away if you make the software in-house \u2013 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\u2019t be experts in chemistry. Any imbalance between these groups means your software will be unhelpful and annoying to use.<\/p>\n 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\u2019ll receive the product you were imagining that way, but it will lack the polished feel of professional software and the benefit of an outsider\u2019s 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.<\/p>\n Software is generally undervalued in the chemistry community<\/p><\/blockquote>\n What becomes clear is that user experience is sovereign. A good integration doesn\u2019t 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.<\/p>\n 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.<\/p>\n Searching for structures<\/strong><\/p>\n A large part of the experience, where it\u2019s 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\u2019t include scrolling through hundreds of inscrutable, text-based representations of those structures \u2013 something I\u2019ve actually seen attempted. If the software doesn\u2019t also understand the myriad of names a single chemical can have, be prepared for it not to work out.<\/p>\n 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.<\/p>\n 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.<\/p>\n