As I spend time with system users throughout the industry, there is a comment that I hear frequently enough to have it register as a recurring theme. It comes in the form of a sometimes wistful, sometimes angry complaint: “our system used to handle that situation just fine but then something happened and it isn’t working anymore.” 

Early on, I would chuckle quietly at these well intentioned but sadly misinformed people. “Silly rabbits,” I’d think to myself, “software systems don’t just stop doing what they did before.  You made a change of some sort and you’ve screwed something up.” There is a slight possibility that while I was thinking these thoughts I may have rolled my eyes or crashed my head down on the table, but I’m sure I was very subtle and no one noticed. 

Software’s chief asset is its thoroughly repeatable predictability… it always follows its own rules. It may run amok when unanticipated or ill-fitting data is pushed through its electronic maze, but it follows its own instructions – nothing more and nothing less. Although its license may expire, its platform or operating system may no longer be supported or its peripherals become unworkably outdated, the software system will never go berserk and decide that it’s no longer interested in aging your receivables. You are the party at fault – you changed something.

And then it dawned on me.  Software’s chief asset is also its greatest liability. It never changes.  How many businesses live by the mantra that nothing is supposed to change? Listen to successful entrepreneurs and you’ll always hear some variation on the shark imperative: move or die. Businesses must adapt, evolve, respond, change and change again. The very idea that things should remain constant is no one’s plan, unless of course it involves software support. 

I’m sure that application vendors have arrived at this paragraph with their feelings hurt. Of course there is change in their world – it seems to them that it’s all that they deal with. But change and usable change are two different commodities. It’s nice to know that your system will now handle Zimbabwean tax surcharges but that’s of arguable value outside of Zimbabwe.  What does this nuance point out? The simple truth is that you are a member of a user community, and that your vendor has invested – quite wisely – in serving the entire community; large-scale deployment is the only way the economics of software delivery make sense. This means that change, while constant, is not intended to benefit you individually. It also means that your needs are prioritized against the rest of a community that can be vast – and way ahead of you in line. The result: although vendors thoroughly support change, the arrival of relevant change can make an eternity seem fairly brief. In the meantime, you as an operator may be forced to improvise, and guess what? Your software no longer functions as it used to. 

The vendor’s favorite rejoinder to make you feel better about the future prognosis for change is to say that they are adopting “agile methodologies.” The agile method (versus the more traditional programming style referred to as the “waterfall method”) uses analyst-programmer teams that dispense with long, formal technical specs; teams generate code based on user stories (a single, manageable feature or requirement) or “epics” (a collection of user stories that work together in a larger context). Sounds fast, doesn’t it?  Although they may engineer more features more quickly, the lion’s share of the process – testing, reviewing, integrating, documenting and deploying and instructing use of the new code remain largely unchanged.  There’s that, and the annoying little fact that changes don’t drop easily into large complex applications no matter how fast you write them. If they did, the vendors wouldn’t tell you all about their new agile methodologies and then announce that your change will be available in September – it’s always September – but then go vague or silent on the specific year they have in mind. 

Most frustrating of all is that in order to get your vendor to react – agilely or otherwise – you must first define your change requirements. That implies that you’ve already beheld the business transformation, mentally visited the shining city on the hill, and you are ready to begin your journey. Just as you feel yourself awakening, magically reborn in the golden dawn of a glorious new day, you’re instructed to take two aspirin, go back to bed and wait for the symptoms to pass. 

Is there a lesson to be learned here?  Maybe not – the rule of thumb seems to be that the bigger and more widely distributed (read “successful”) an application is, the harder it is to change. Drat the luck that you chose an industry leader to supply your application – there’s a catch to everything, isn’t there? Sometimes it feels like your choices boil down to “small, stupid but trainable” versus “large, competent and immovable.”  Neither choice actually provides the active adaptability that ongoing operations require. 

But really, the most mysterious change is the one that hasn’t been made. Although vendors provide products that anticipate the many moods of hospitality, serving the general public and enabling personalized guest recognition, providing real time pricing updates and offers, and maximizing return for the operator emphasizes the industry’s need for flexibility in every area.  With the emergence of SaaS (Software-as-a-Service) offerings, what the vendors will learn is that software that can’t change easily will be changed out. If the technology doesn’t become more adaptive the to user, the user will adapt to alternative providers.

Asking users to remain still while the world changes in no longer an option.