Opinion: Laboratory Software Issues from Hell

In my career, I have dealt with many different laboratory software vendors.  Regretfully, not all encounters have been straight-forward.  Since ultimately these products are used for patient care, I had hoped that there would be a sacred trust to do what is best.

Things that bother me:

  1. Current state:  whoever prepared it for the client, didn’t care or understand the local processes and came up with a generic:  Order it, collect it, receive it, do it, report it for each and every test.
  2. No training for super users:  more like lambs being led to the slaughter.  They will obey the vendor out of fear of making a mistake.
  3. No discussion of options:  pushing us to take the default setting—not even offering the available options.  The only way you find out there are available options is because other staff have used the same software at other institutions which used these options.
  4. Corrections to build:  only giving one shot to do it right, further corrections cost $$
  5. Scenarios:  vendor shows specially crafted scenarios that “work” but when you ask the vendor to do a random, non-scripted scenario, it crashes.
  6. Scalability:  limited scalability on client’s chosen platform.  That may force a rebuilding of the software when the limit is reached.
  7. Reference site does not match the test volume or activities of the client, uses different platform, and thus you cannot make a valid assessment.
  8. Performance issues:  if you don’t know why the system is slow, you can add more hardware (RAM, disk space, etc.) and try again—it can’t be due to the software design!
  9. Handling of requests:  does not permit your local IT staff to make changes, must send it back to the vendor for $$
  10. Waiting until hell freezes over:  will we get the corrected/updated package during this reincarnation?
  11. Interfaces:  an acceptable communication link is when one side speaks Sanskrit and the other Algonquin and they both hear each other, but who cares if they understand?
  12. Waiting for Godot:  God forbid if your equipment needs an interface not currently available:  how many cycles of the big bang can you wait?
  13. Champions or Heroes:  make a class of users who are to be evangelists for the new system and have them undergo sensitivity training including actions that are culturally irrelevant.  Don’t tailor it to local sensitivities or customs.  Will this convince the staff how useful the software is?
  14. Relevance of vendor experts:  Assume everyone understands what maple syrup is or comes from Kansas.  The expert assumes everyone has the same background as his/hers.  Who in the Middle East has seen maple syrup being made?  How can that analogy be useful for building software?
  15. Describe all reference units in feet/pounds/inches/furlongs/fortnights—no metric.  Do not use SI.
  16. Mix 24-hour clock with 12-hour clock:  what does 12:00 mean?  How do you measure time intervals?
  17. Consulting companies:  They are supposed to assist the client with the settings, but do they have the client’s best interests at heart?  Some are good spin-doctors and transfer blame to the client’s software staff when it is really their responsibility for the build.
  18. Rush, rush, rush:  Administrative powers who just want everything done quickly whether or not it is correct or validated properly, who cares if the processes built are right?