Three Ways to Ruin Your LabWare LIMS / ELN and Other Systems


I had made some previous posts that talk about the fact that you need to be careful what you do when managing your LabWare LIMS / ELN or even other brands of these systems. The last such post was poorly titled as How to Create Huge Problems With Your LabWare and Other Systems because it was more of a warning than a “how to” guide. Today, I will talk specifically about the LabWare system and the terrible things people do to it to make it unusable. However, these tips often can be used with other brands, as well.

Some of you will read this and think that it is the kind of list of things you would do on the day you become entirely unhinged. However, these are real things that real people have done to ruin their implementations. I have not yet heard that these implementations were ever able to be fixed and move into production but, if they did, they probably had to entirely start from scratch. As such, here are three things that you can do to make your system unusable:

  1. Reckless use of the Wait() command. At some point, when you find your system is out of sync running some functions before others and not in the order that you intended, rather than find a way to get it all running in the correct order, throw in lots of Wait() commands. As the system gets yet bigger and continues to slow-down, just add more time into these Wait() commands. At some point, users will get frustrated. If your wait times are set into the minutes, you should warn users with a MsgBox() telling them to go get a cup of coffee or do other work. After all, they get frustrated when you have them just standing there doing nothing but, um, waiting. They will spend most of their day, now, peering around the corner at their screen, wondering WHEN OH WHEN will the system come back to them but, after all, they probably have a lot of other work they could be doing so they’ll keep busy and, at some point, they’ll be gone for so long that they’ll forget they even have a LIMS so it’s all good.
  2. Giving end-users untested programs. You can hack something together and just hand it to the user without even trying it. After all, isn’t this what “rapid application development” and “prototyping” mean? (no, not really, in case you actually were wondering) Do this every time the user asks you for new features and they’ll get tired of asking. They’ll give up. The LIMS might not be more usable than it was but the users will stop pestering you and you can get back to streaming whatever TV show you need to get caught-up on.
  3. Pretending that the programming tool doesn’t need management. In our industry, we call the programming we do at the executable level “programming” and the programming we do at the higher level “configuration” but this doesn’t mean that both don’t need management. As just about everyone working with these tools will tell you, not just anyone can become a LIMS Basic, VGL, C# or any other kind of programmer. They need training, the code needs to be managed, and you can’t just let anyone come in, hack just anything together, and then be surprised when it causes problems in your system. These programming tools are powerful, they change data, they cause things to happen that affect other users – ignore that at your own risk.

The other benefit to causing these problems is that, if you want to ensure you have work for a long, long time, once you ruin these systems, in too many cases you can turn around and just ask for more money to fix all that you just destroyed, giving you more longevity and an assurance of work for a long, long time. After all, it’s all about charging the customer as much as possible to make the project last longer than in providing the best project possible, I hear.  🙁

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


2 responses on “Three Ways to Ruin Your LabWare LIMS / ELN and Other Systems

  1. Also, do not implement functionality in LimsBASIC that mimics built-in tools. I am trying to maintain an environment where a previous LIMS Admin did just that: “I don’t know how to properly implement this module. So I’ll just program a dozen or so custom menu options to do the same thing that the built-in menus do!”

    Because poorly written, not-at-all-documented, custom code is never a problem later. Technical/Code debt? What’s that?

  2. And then we see the opposite, too, where developers find the slowness frustrating and do an end-run by mimicking it with other tools, usually SQL commands. Now, by doing that, you’ve built something that does an end-run around all the security, triggers, etc…

    As for LIMS Basic (or VGL or others), I have actually heard people make the excuse that they don’t have to document it because it’s “self-documenting.” When I hear that, am not sure whether to laugh (because that’s hysterical) or cry (for their project).

Leave a Reply

Your email address will not be published. Required fields are marked *