From Oppenheimer to Fargo: the ups and downs of ingenuity

Photo credit: Tim Mossholder on Unsplash

Is that really a Palm Pilot?

Coverage of the recently released biopic, Oppenheimer, revealed that the film was so long that the reels at IMAX cinemas needed to be modified to contain its full eleven miles. Observant viewers with an interest in technology noticed something much more surprising, though: the IMAX reels seemed to be controlled by something that looked like a Palm Pilot, a Personal Digital Assistant (PDA) from 2002. (For younger readers, a PDA was like a smartphone, only without a touch screen, the ability to make calls, connect to the Internet, take photos or store all your music. You may wonder why we spent so much money on them. In hindsight, me too.)

It turned out that the setup did not actually use a Palm Pilot, but a Palm Pilot emulator running on a Windows tablet - which somehow makes it seem even more weird. An obsolete device has been converted into software and presented as a physical interface on another obsolete device. Coupled with the mild shock at the realization that IMAX cinemas still use physical film at all, the whole configuration seems like a steampunk mashup of technology from different decades.

For people who work with enterprise technology in large organisations, of course, there is nothing strange about this setup. It’s not even necessarily the result of bad choices: the Palm Pilot solution was familiar to projectionists, and when the device was discontinued, the technology team found a way to keep giving their users the experience that they knew. Enterprise technologists are used to creating such solutions all the time: the difference is that, unlike the Palm Pilot and the giant reel of film, the different generations of technology are invisible to most users.

For example, when your bank pushes a new version of its mobile app to you, that doesn’t mean that all the systems that sit behind that app are new. Rather, when you press the virtual button on your phone to initiate a transaction, you trigger a series of events which reach back into the past, running code which was written long before even the Palm Pilot was thought of. It is part of the job of enterprise technologists to knit these capabilities together to give you a seamless experience, and it is their ingenuity and the malleability of software that combine to make this experience possible at all.

So, this ingenuity must be a good thing, right?

I believe that is true - up to a point. Ingenuity is good when it enables us to create experiences and capabilities out of components that were never designed for that purpose. However, there comes a point when we try to make components perform in new ways and they start failing, or become so complex that we don’t understand them any more, or where the effort of trying to keep the mashup going outweighs its benefits. Unfortunately, these thresholds are rarely obvious or crossed in one go: rather, they are the results of many tactical and expedient decisions that seemed like a good idea at the time.

For example, I have seen a batch payments system turned into a ‘real time’ payments system by running the overnight batch multiple times a day. This worked when ‘real time’ meant within an hour, but started to fail when ‘real time’ began to mean, well, real time. By that point, the behaviour of the intra-day batch was so engrained in the architecture, that unwinding it was an intrusive, delicate and expensive operation.

This tendency of ingenious solutions which spiral out of control reminds me of another film, this time one of my favourites: the Coen brothers’ Fargo. There is much to enjoy in Fargo, but I am always particularly fascinated by the character of Jerry Lundegaard, the hapless car salesman whose frantic actions drive the plot. The intriguing thing about Lundegaard is that he must know that his schemes are fragile and doomed to failure, but he keeps on going, continuously improvising and innovating, trying to stay one step ahead of his fate. And, every time he buys himself a few more hours, minutes, or seconds, he makes things more complicated and worse for everybody.

Perhaps those of us working in enterprise technology should learn to recognise that Lundegaard feeling. We should try to spot when we are no longer using our ingenuity to prolong the life of useful assets, but frantically using string and sealing wax in place of steel and concrete. And at that point we need to tell our sponsors and stakeholders, to explain that, even though they may not be able to see it, they are sitting on top of a shaky edifice which needs an overhaul. Such conversations are often difficult but, as ever, we have a duty to explain.