In what I can only describe as a burst of creative insight, I made up a new word recently that I believe encompasses the angst of technical professionals everywhere: simplexity.  To validate my status as an innovator and architect of the next generation of the English language, I logged onto the Internet to confirm that I was indeed the first to utter the term.  What I discovered was not as validating as I had hoped.  I know I made that word up because I was there at the time, but now it appears that I may not have been the very first to do so.  There were a few trifling matters like registered trademarks and the general use of the term in science, health, electronics and education over the past 15 or 20 years, but let’s not get bogged down in details.  Instead, let’s spend some time discussing my word the way that I want to use it. 

    My simplexity references the vast gulf that can lie between concept and implementation.  Many good ideas begin as simple ones, but as the process of pushing theory into practice begins, one often realizes that simple isn’t straightforward, comprehensive or easy.  Stop reaching for that big red button, if there were simple answers to big problems, they wouldn’t be big problems in the first place.  As an example, let’s take an issue with no social bias to it… something simple, like healthcare.  Notice how easy it is for us to engage in coast-to-coast handwringing and then sing our new national anthem, “Oh, Say Can We Fix Healthcare?”  This very partisan issue hasn’t devolved into a media circus because there are idiots in Washington (which there are) but because there are no simple solutions to complex issues.  We can’t just suddenly build a system like it should have been built in the first place, waving away entire industries built on decades of laws, practices, precedents and profits. 

    The 14th century philosopher and theologian William of Occam opined that it is best not to overthink things.  His famous viewpoint on simplexity is known as Occam’s Razor and it is typically paraphrased as, “the simplest answer is usually the best.”  In and of itself, that pithy little turn of phrase is a huge simplification, and not a very accurate one at that.  If simple answers are best then there is an obvious solution to the healthcare problem: don’t get sick.  A better statement of Occam’s view of simplexity is that the best solution is usually the simplest one that effectively addresses the entire problem.  

This is the point where we in the technology sector typically begin to feel what is often described as the “wadding of the panties” or, if you’re British, the “knotting of the knickers.”  What may be presented as a simple problem in search of a simple solution (like a simple check-in screen) can be a situation fraught with simplexity. Sure, it’s easy to make a simple check-in screen.  Back in my programming days, my personal best effort reduced the entire check-in process to a single dialog box: Check this guest in? Yes or No.  As comprehensive as I thought this solution was, the design committee saw a number of potential gaps: what if you don’t speak English?  What if you wanted to know which guest you were checking in and, for that matter, into what?  What if there were other check-in requirements such as confirming guest preferences and verifying room rates and upgrading accommodations and authorizing credit cards and issuing keys and taking down wakeup calls and giving out loyalty points?  It doesn’t take a 14th century philosopher and theologian to see that there are times when the simplest answer isn’t an answer at all.

The typical software engineer’s solution for simplexity is to hide the “plexity” behind the curtain in database options and entries, system parameter settings, user preferences and software defaults.  In theory, what remains for clerk and guest is pure simplicity (and I mean that in the nicest way). 

    Unfortunately, the real requirement is not simplicity, but rather simplicity when the situation is simple and rapid access to complexity when the going gets tough.  However, this introduces a kind of software schizophrenia: a simple kind of complexity, or, if you will, complex matrices of simplicity. What users perceive as a simple software solution is usually a derivative of the 80/20 razor, which implies that the best solution is the one that works most frequently. (The 80/20 rule does not mean that the solution is 80 percent effective but rather that 80 percent of the time it’s 100 percent effective and 20 percent it doesn’t do as well.  If it averaged 75 percent effective in the exceptional cases, overall the program would be 95 percent effective.)  The reality is that when dealing with machines, variables, service and the general public, 80 percent is a lot – maybe even more than one should rightfully expect. 

    I think a good example of this reality shows itself plainly in the process of reservation systems quoting room rates to agents: no matter how many business rules are applied by any combination of revenue and channel management systems, the result can almost invariably be overridden by the clerk to produce yet a different, custom result.  Why?  Because no matter how accurate the rate schedules or precise the business logic, guests insist on having different needs and expectations.  The clerk override option is not a logic failure but instead is built-in flexibility that allows the system to recognize and use the rate category I call “some other price we didn’t think of before.”  The goal of a built-in, 100 percent software solution is noble, but the winds of change blow too stiffly and frequently to make that practical for either users or developers.  As a CFO of my acquaintance religiously likes to point out, “The cost of perfection is prohibitive.”  

    But let’s sidestep the issue of cost (and those incredibly long development cycles) and pretend for one moment that a perfect solution is possible.  Ask yourself how long you think it will retain its perfection.  How long before some irresistible force (like a change in policy, statute or service standard) demotes it from perfect to okay?  Worse yet, how long before one of those irresistible forces even takes “okay” out of play?  There are plenty of examples of changes – particularly those forced on us by governments and financial institutions – that don’t just lower application efficiency from 100 percent to 80 percent.  It can be a quick trip from 100 to zero when the change affects every guest or every transaction.   

    To me, simplexity is not just the gap between here and there, but also the yearning for easy and orderly solutions to the endless complications of modern life – solutions besides death, I mean.  But to qualify as a genuine solution, the proposal has to rise to the problem while still being practical enough to deliver results.  The art of navigating those extremes is the real razor.  Both Occam’s and mine lean toward the simple option, but, to quote a 21st century philosopher and technician (okay, it’s me), “Ain’t nothin’ easy.”  Except maybe making up your own words, and then only if you hurry. 


Michael Schubach is a regular contributor to Hospitality Upgrade and continues to break the rules of the
English language. He can be reached at [email protected].




For related articles on this topic please see:

• An IT Checklist for the Start of a New Year - Making the best of your IT budget
• But I Like Technology
• E-Marketing Responsibly - How to Avoid the Spammer Label
• In Praise of Geeks
• IT MANAGERS ARE ATTACKED FROM ALL SIDES - JUST ANOTHER DAY IN IT
• It’s All in the Package
• Securing Your IT Assets – The Time Is Now