Twenty-five years ago, I worked on an MS-DOS Point-of-Sale system, or POS.
Our POS device was designed to support multitasking, network messaging, fuel dispenser control, credit card readers in the dispensers, and a handful of other serial devices – devices like cash drawers, customer displays, and barcode scanners.
It was an app written to work atop an operating system that was definitely not designed to handle what we threw at it.
I earned my serious, hardcore developer stripes on that system, writing my fair share of interrupt controllers, network protocol queues, and terminate-and-stay-resident drivers – as did some of the most talented developers that I ever had the pleasure of working with.
As I mentioned, a core function of our POS system was controlling fuel dispensers.
Now, it would be nice if all makes and models of fuel dispensers used the same type of wiring, shared the same communications protocols, or had the same feature sets.
No such luck.
An early design decision we made was to use a 3rd party “universal black box”, programmed to abstract the control of all manufacturer’s fuel dispensers, so that we could focus on higher-level fuel functions, like authorizing and cashing out transactions at the pump.
We learned – unfortunately – that our “black box” approach gained us zero actual advantage. We spent way too much precious time, simply trying to understand all the least-common denominator compromises that our “black box” solution made – time that we could have much better spent understanding the pumps ourselves – which was what we really should have been doing all along.
When a feature is supposed to be core to your platform, or critical to its operation, you have to own it completely.
It’s a lesson companies are still learning today.
There are absolutely no shortcuts to success.
Go, and be you.