Simplicity: Too Much of a Good Thing?

Like many engineering types, I strive for simplicity. I seek to avoid excess complication. I rely on analysis to tame complexity and I rely on rigour to help me manage it.

That said, I am very cranky about simplistic people and their simplistic thinking and their simplistic solutions to complex problems.

To be concise, simple solutions lack complexity while simplistic solutions suffer from being too simple, from being insufficiently complex.

In practice, I find that simplistic thinking is the result of poor analysis, of not digging deeply enough, of accepting apparently simplicity as the whole story.

I feel rather self-indulgent today, so I will put this into doggerel:

Simple is a virtue,
Simplistic is a vice.
Simple might not hurt you,
Simplistic is never nice.

So what is an example of simplistic thinking? Consider patient identification; one of our systems is used to support dealing with the public, which requires that it support patient identification. At first blush, this is simple:

• require that the patient give you their unique patient ID, probably on some kind of card you gave them;

or

• require a photo ID with name, date of birth and sex

Since the client organization already has a patient registration system, they objected to our claim that we needed to build a patient identification support module. We had to do it against their objections and then only bill for it when they saw its value.

What complicates this seemingly simple task? The actual answer is horrifically long and complicated, so I will an abbreviated reply which will still make the point:

• Women often change their names when they get married; their pre-existing paper work, orders, etc, do not magically change with them, so it is helpful to keep previous versions of names, marked as not canonical, to help ensure that the driver's license / printed report / old information mismatches are not evidence of error.
  
• Children do not have photo IDs and are often known by unofficial names. Is young Billy Doe actually Ralph W. Doe? R. William Doe? Bill Doe Jr? Is this the former Babyboy Doe? Perhaps he is the former Boytwin1 Doe--or is he the former Boytwin2 Doe? By keeping a history of these transactions we can support confirming that you have the correct child, even if the caregiver can't remember which kid had the allergy test in July, as opposed to the kid who had the allergy test in June.
  
• Alas, people make mistakes and sometimes these mistakes line up with real data. There can be two John Does, one born 4/1/1941 and one born 1/4/1961 and if you mistype and have to search, you might pick the wrong one, in which case a custom module which says "this patient does not have a relevant order, but the other one does: are you sure?" will really save on dangerous and expensive patient identification mistakes, no matter how plausible those mistakes might be.

As a vendor of custom solutions for medical information process automation (yikes! what a mouthful), I am rarely called in because a situation is simple; if the problem had a simple, obvious, excellent solution, someone would have implemented that solution. I am only called in when things are complicated, hairy, ugly or all of the above. While I do what I can to make my designs as simple as I can, some problems can only be solved with involved and complex solutions.
 
Recently this pet peeve of mine has been elevated to a business issue as
our firm more frequently encounters simplistic thinking in our customer's senior management. These managers, from their lofty perches, are issuing clean, simplistic edicts which do not match the reality in which we find ourselves.

Worse, we are losing sales to less ethical competitors who promise clean, simple solutions to murky, complex problems. These solutions don't work, of course, but by the time this is well-established, the situation is the new normal and everybody loses.

So strive for all the simplicity you can muster, but shun the simplistic with all your might.