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. Here is more information can also read more about the LabWare LIMS system.
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:
- 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.
- 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.
- 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/
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?
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).
Who says that any change in the system, not just the ones that requires coding, does not require to be documented knows nothing about electronic systems, product shelf-life, project management and team-working.
I would avoid people having this kind of mentality on be part of any LIMS project. Let me know how they will work to expand the current system with new functionality for covering new requirements if they documented nothing!
I can’t believe it !!!
The worst thing is when code is created by people with no experience in any, the LIMS platform + programming + the industry + the regulatory rules, and when something is not working as expected then the put the eyes in the product as this is a bug in the product.
All depends on the level of complexity on the customization side, in a middle-high customized system having some notions about programming is not enough even considering this programming as a high-level one where the complexity is lower.
Fran, you’ve got so many great points, here. To expand on just one of them, and my pet peeve, by the way, is that we get so caught-up in the terms “configuration” and “customization” that we lose sight of the issue that a change is a change. A complex change needs more rigorous testing than a simple one.
Just to give readers some idea of what you’re talking about, here, let’s take something like a product specification. Some people think of these purely as “configuration” but they are incredibly complex even without adding code to them. In most products, product specifications are full of lots of features that could be used, to start with. They tend to need more testing than code in something like a sample login template that is a single line to pull information, especially from a record in-context.
So, as just one example, regulated customers tend to have special OQ (Operational Qualification) scripts just to address these objects. Or analyses with calculations are another example of something that might have some kind of testing guidelines. That’s as opposed to a simple list where someone probably just spellchecks it and verifies that the items are correct.
Totally agree, what differ from one object to the other in terms of testing should be the stress level that you have to consider on the testing scripts, consider any object in place as non testing required is a risk that I would suggest to nobody. This kind of testing in a optimistic mode just derives in one reality, problems to fix what those objects not tested will cause in production.
I think a couple more examples would be good for this discussion:
LabVantage LIMS and Groovy: I was talking to someone using the LabVantage LIMS, which allows for using Groovy in some parts of the system, such as the pages. I asked what kind of testing they did when they added Groovy. Their response was, “None because Groovy isn’t a real programming language.” Well, that’s debatable but, regardless, you need to consider whether testing is required. One line of Groovy to get some values on the page is evident when you bring up the page and the information is there (or it isn’t) but when you add more than that, you need to think carefully about what point you need to do further testing.
SQL (Structured Query Language): Lots of people speak of SQL as a “scripting” language. That’s fine but it’s just a label – it’s just something to call it to help categorize it. It doesn’t mean that we don’t need to test it. Some of the queries we write are more complex than some of the other code we write in what we think of as the “real” programming languages. I’ve been writing a query with a pivot table, nested SELECT statements, and a number of other things, that’s so complicated that I sometimes think writing a program would have been easier to write and easier to test (there’s a specific why it’s a query, but I’m just pointing-out that there are other options).
There are lots of ways to collect data and, with the complex data we work with, they need some amount of testing to occur, regulated system or otherwise.