The Negative Effects of Bad LabWare LIMSBasic

We have lots of discussion in the industry regarding who should be programming and which what tools. In my last post, I was comparing Thermo Scientific SampleManager’s VGL versus C#. Today, let’s discuss LabWare LIMSBasic.

LIMSBasic is the proprietary language created for the LabWare LIMS / ELN. Regardless whether we call it a configuration tool, a scripting tool, or just call it Jeff, it’s still a programming language. And, like all programming languages, we should train people to properly use it. Similar to VGL, LIMSBasic seems initially fairly easy to use. Even non-programmers can write small amounts of code, successfully. In fact, they’re required to. When creating new templates, such as sample login templates, it doesn’t require a programmer to set them up but they do often require some amounts of LIMSBasic.

But similar to VGL, it’s deceptively simple when you initially begin these programs. People with no programming experience can fairly easily turn these into unmanageable programs. Even people with programming experience but no LIMSBasic experience can turn them into something rather horrible. At this link, you can read more about LabWare LIMS and other issues.

Issues

Maintainability:  First of all, there are specific places in the system meant for certain programs. If they aren’t put in the right place, it’s hard to maintain them because no-one would expect to find them outside the places they’re meant to be. Out of frustration, inexperienced people will put them somewhere they don’t belong and program the living daylights out of them to make them work.

Performance:  This is a system extremely sensitive to having too many events and triggers running at the same time. Adding too many things into one place can cause performance issues. LIMSBasic is a slow tool, to begin with, and it’s not hard to go overboard and entirely slow down parts of the system with too much programming.

Upgrades: Regardless what anyone says, the more code you write, the harder any upgrade will be. Some upgrades are relatively painless but some upgrades are somewhat more work. During major upgrades, especially where the interpreter’s behavior seemed to change, slightly, much more testing is required. For validated systems, this seems especially critical, but even non-regulated systems require a fuller testing battery when these types of changes occur.

Finally
I’ve been on some great projects where people are professionals and know how to get the best out of the LabWare tool. I’ve also run across some systems that were so abysmally-implemented that one might think the people involved in the implementation might feel some sense of shame, except that they don’t – they got their money and satisfied that the hack job they performed is over and they can move along to another victim, er, I mean, customer.

Additionally, many of us know of those projects where the system is basically just unusable – that were so badly implemented that they can’t be used or that provide no real added value. A couple common issues in these cases are that the LIMSBasic was put in the wrong place where functions are firing in a way that the data becomes out-of-sync and/or so much code was added to critical areas that the system is too slow to be usable. In these failed systems, both are typically true.

The final issue is that the community seems to spend it’s time placing blame on anyone but the people who caused the failures. Maybe it’s time to stop pointing fingers and to do a true project autopsy to determine the root cause of these failures. It’s easy to say that it’s the fault of the programmers involved but, in large projects, the fault usually lies higher than that. After all, the developers go where they’re sent when they work for a larger services group. They don’t typically have a choice which projects they work on.

Gloria Metrick
GeoMetrick Enterprises
http://www.GeoMetrick.com/