In my last posting, I wrote about appropriately managing your LIMS, ELN or LES system in Appropriate System Admin for LabWare and Other Systems. Today, I want to talk about an inappropriate way to manage your system.

When you have a system that has a proprietary programming language, such as the LabWare LIMS / ELN’s LIMSBasic or the Thermo Fisher Scientific SampleManager LIMS / LES’s VGL, you should NOT use a third-party code vault or code management tool to try to manage the code. They just don’t work.

Some of you out there are reading this, beating your chest and saying something like, “But I’m REAL programmer and a I need a REAL tool to manage this code.” I feel for you. However, too many people have wasted too much time trying to wrangle these programming tools into compliance with tools that they were never meant to work with. If you feel that offended by this, you probably should move along to work with programming tools that are less offensive to you.

Rules of Thumb
These are not ALWAYS true but they are good rules of thumb. You should always check with an expert before making any assumptions, though:

  1. Proprietary code management usually cannot be done with third-party code vaults or code management tools. If the system doesn’t supply anything to properly manage the code, then you just have to live with it. All the complaining the world won’t change this so learn to live with it or find something else to work with.
  2. Non-proprietary code usually CAN and SHOULD be managed with whatever code vault or code management tools are provided for it. So, if you’re using any of the .NET programming tools, you probably can and should use the related tools to manage and deliver these solutions.

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

One Thought to “Code Vaults and Management – Inappropriate Use”

  1. A related problem with these Integrated Development Environments (IDE’s) is when somebody tries to save or archive a fixed snapshot for some reason by creating a version with a read-only database. It turns out one can’t write reports in the environment without actually writing to the database! I have seen this happen with LIMS systems, but also on a large SAP project – even a minor change to a data extraction report, even just reformatting, requires the record for that report to be updated in the SAP database and … oops …

Do you agree? Disagree? Have something to Add? Here's your chance - make a comment!