When business leaders are looking into capturing business data and automating processes, there are a lot of options out there. They could choose to have someone build out an Excel sheet to capture the basics, they could hire software developers to build a full system, or they could try something in-between: a so-called “Low-Code” or “No-Code” platform. These platforms are gaining in popularity and power – but are they a step in the right direction, or are users getting lost in the weeds searching for a “Silver Bullet”?
A History Lesson
Back in the late nineties, my father worked for a Y2K conversion software company that was born out of a large insurance company. At the time, companies had realized they had a massive problem on their hands – millions upon millions of lines of software code (most often COBOL code) that had used a 2-digit date field to store the date, and therefore would not be compatible once the century rolled over.
I’m sure that many of you are familiar with this problem since it was a media frenzy for a while. Would the power plants shut down? Would the missiles all launch? All types of doomsday scenarios were projected.
Despite this frenzy, my Dad’s employer found that an amazing number of organizations were waiting until the last possible minute to begin to address the problem. Their parent insurance company had been smart – they had started fixing their code very early – having started fixing the issue in the late 1980’s.
But even as late as mid-1999, only months away from this impending doom, many firms were calling the company and asking something along the lines of “We have a hundred million lines of code, none of which is compatible, can you help us?”
In most cases, the answer was no. It was too late. Projects were allocated, time was spent, and there was no way that anyone could fix 100,000,000 lines of code with that short of a notice. They had waited until the last minute, hoping there could be a magic solution to their problem. Hoping perhaps, that “someone from the government” would swoop in and make the problem go away.
What my Dad always used to say was that they were “waiting for a silver bullet”. In sales call after sales call, he would have executives tell him they’d rather wait and see what happens, so he’d walk out shaking his head. For the most part, the vast majority of companies finally did fix their issues – the laggards though, waited and ended up either losing money, losing records, or having to shut down portions of their business until the faulty code was fixed.
In fact, many companies were still fixing their Y2K bug issues well into the 2000’s. They just went without reports or electronic processes for a few years.
What did all this re-work and cleanup they created cost them in the end?
Defining a Silver Bullet
Every impending change in the way an industry does business has a corresponding “Silver Bullet”. Some people think global energy needs will be solved because “someone will just invent a more efficient car”. Whenever a new regulatory policy is passed in Congress, people think that “it’ll never actually be implemented”.
In our particular business of software, there’s a slightly different “Silver Bullet” that we often run into: the idea that instead of building an innovative solution when the need is pressing, you should wait, because maybe someone will come out with an off the shelf solution that does what you need.
Or, a slight variation is, maybe you can use a low- or no- code platform to build what you need. Or maybe you can squeeze it into Excel or Microsoft Access.
More than ten years ago, I wrote a post on StackOverflow addressing one aspect of this question. At the time, I was seeing a lot of clients running extremely complicated business systems on Microsoft Access databases. While Access is a great tool for someone learning programming, and for making small business and home-based databases, it was never meant to be an enterprise platform for large groups of people to manage millions of dollars worth of transactions through.
But time and again, that’s just what I saw. Massively complicated Access forms being used by hundreds of people.
Most of these users knew that Access wasn’t anywhere near their ideal solution. Almost all of their users would agree that a nice web-based application or desktop app would be much easier to use and a lot less limited.
Why did these companies choose to leverage such a tool to solve the job, rather than going with best practices? Why do companies create piles of Excel worksheets, a situation that has almost become a trope among software developers?
In my experience, there are a couple of key reasons.
Why Office Apps?
Firstly, availability of tooling. In most cases, Access and Excel are installed on users’ desktops (though I have seen situations where IT specifically prohibited Access), so all users have to do is fire it up, drag and drop a few forms, and BOOM – enterprise software!
If a user wanted to create actual software code – would they have as easy access to the tools to do so? Would they know to install Visual Studio or Eclipse or whatever IDE you prefer, even if they did wanted to learn to program “for real”?
When a user wants to develop something to help them do their job in Excel or Access, it’s easy. The tools are at their fingertips and they are easy to learn and get something put together quickly.
Secondly – cost. If your team is limited to a few business analysts and you can’t afford a programmer, you can still create all kinds of solutions using these programs. Companies are very bad at assessing the risk and opportunity costs of certain technology choices – the Y2K bug being a good example. The truth is, if they were able to track and add up the salary cost of dealing with a the problems these “crutch” systems create, it would easily justify hiring a software developer.
Of course, that assumes their developer would do it right. They also might come in and make a total mess of it, or work there for 3 months and leave. As an industry, software developers don’t necessarily have the greatest reputation for a commitment to success.
The Tipping Point
Microsoft Access and Excel clearly can be very useful in automating a small task or for quick calculations. The difficult truth is that these platforms can only grow so much before they need to be replaced. Often, as users rely more and more on these apps, they make many little changes suiting them to their exact needs. They eventually reach the point where it is a core function of their business process, the Tipping Point.
There is no perfect way to know if you are about to reach the Tipping Point but you may want to ask yourself, “am I struggling with how big this has gotten?”
“Is it near impossible to make changes to the system to make it do what I need?”
“Do I run into conflicts when multiple users work in it?”
“Does it perform slowly because of how much it is doing?”
