I am working on a novel, my second.  It involves a serial killer. There is something richly cathartic about killing someone with bits and bytes. If you are in a bad mood, it can be calming. If the killing does not provide the calming effect I had hoped to achieve, rekilling him in a more vengeful manner usually does the trick.

The novel involves the skills of an FBI profiler. If you have read any of the books on profiling you would think it an exact science.  Chapter by chapter the writer extols the successes of profiling—this profile worked, that one worked.  According to how it is spelled out in the book, one would want to ask, if profiling is so successful, why do they not use it on every case?

Perhaps because there are unwritten chapters, chapters that never make it into the profiler’s handbook.  The reason those chapters do not make it to the book is because it sort of defeats the purpose to print cases in which the profiles that were created did not match that of the killer’s—white male in his mid-thirties, wooden leg, drives a Prius, and enjoys watching Dancing with the Stars.

When I thought about it, it occurred to me that business software is pitched a lot like profiling serial killers.  You never hear about the bits that do not work.

Think back to when you and your colleagues watched various processes of your software being demonstrated—add a patient or a customer, schedule an appointment, write a new script.  The functionality was so smooth it brought a tear of hopefulness to the eyes of the prospective users.

In a recent conversation I learned of a patient scheduling system that had more than five-thousand user screens.  That is a five followed by three zeroes; almost enough to have a separate screen for each patient.

Like the author of the book on profiling who only wrote about the cases on which his technique worked, software vendors only show potential buyers those processes that function smoothly. In an EHR system, vendors show how their software works in a real-life setting with only one thing missing, a patient with which it must interact.  A rather critical missing part of the functionality puzzle if you ask me.

The entire situation, that of acquiescing over time to having to use bad software, reminds me of the experiment of the frog and the pot of water; drop a frog in a pot of boiling water and it leaps out, place it in a pot of water and gradually raise the temperature and the frog will remain in the pot until it is cooked to death.

Users of bad software are a lot like frogs in a pot. They never quite get up the moxie needed to jump out of the pot. More often than not they allow their situation to worsen until it is too late.