In 2004, I landed a job as a junior system admin at a local ISP. The owner was a super tech-savvy guy. I’ll call him Peter to keep things simple. He had a CS degree and had done software development for a while before it was mainstream. Like many folks, he started his company to get decent cable internet at home. Turned out over a thousand neighbors had the same problem!
What blew me away was how organized Peter was. He knew Visual Basic and MS Access inside and out. So, he just modeled all the company’s processes using those tools. Nearly everything was automated!
Here’s an example for you. The receptionist would enter user payments into a file on a shared drive. That file got parsed on a schedule, data added to the Access database, and reports generated. Peter always knew how the business was doing, where things went wrong, and all the projections. Impressive.
Let’s look at MS Access and other attempts over history at making programming languages and tools for non-technical folks. We can learn relevant lessons when evaluating no-code tools today by exploring those early efforts. Learning from the past is a great way to highlight considerations as we see the rise of no-code solutions and their promise to open up tech to more people.
The First Programming Language for Business (1960s)
In 1959, there was a real revolutionary attempt to create a programming language that everyday businesspeople could use. They called it COBOL.
COBOL was one of the first “high-level” languages, using English words instead of just processor commands. It was put together by some big brains sponsored by the US Department of Defense, and it quickly became the go-to language for business systems.
But by the 1970s, COBOL started getting a bad rap. Students were told it was a “dead language,” and no one studied it anymore.
The idea behind COBOL was solid — make programming more accessible to non-technical people. But in practice, business users found it too tough to learn, and even engineers needed help with the simple syntax meant for non-programmers. COBOL was supposed to be explicit and leave no room for assumptions.
In 1975, a famous computer scientist Edsger Dijkstra infamously proclaimed that “the use of COBOL cripples the mind.” Ouch!
Funny enough, even in 2023, there’s still demand for COBOL engineers since systems from the 60s and 70s need maintenance. And companies pay big bucks for that antique COBOL skills!
The story of the COBOL language shows that making programming accessible for the average person is tough. The intentions were good, but adoption suffered. Even today, we still rely on old systems built with these early tools aimed at accessibility.
Attempting to Democratize Databases (1970s)
One tool actually designed for non-technical folks was SQL! I was surprised when I learned this. SQL is the standard language for working with relational databases for anyone unfamiliar. It lets you write queries to read, analyze, and manipulate table data. It’s pretty complex.
It was developed back in the 70s by some brilliant researchers at IBM. Within a few years, it became publicly available and blew up, becoming the standard database language by the 80s.
The idea was that SQL would let regular business users work more efficiently by giving them direct access to data; no programmers needed! Folks could get data insights, make informed choices, and set up automation — the sky was the limit.
It didn’t quite work out that way. Even today, I see some senior engineers who aren’t SQL pros. It proved way more complex than expected, with only basic queries being manageable. The promise of easy access fell short.
The tricky balance of making data accessible while also having depth and flexibility wasn’t really achieved by SQL too. It is widely adopted and became a standard primarily because of its robustness, yet it’s used mainly by engineers.
Microsoft Access — Low-Code Solutions Emerge
I was just a kid in the ’90s, but by the 2000s, I saw MS Access become popular as a low-code tool to build apps. You could quickly whip up databases without coding skills or SQL knowledge. People made complete applications with decent GUIs in Access, and they were pretty serious!
Later, Microsoft pitched Access as a low-code front-end for pro databases like SQL Server. You could also do automation via simple point-and-click macros. Very similar to today’s no-code tools!
I have never used Access myself since I dove into UNIX and coding early on. After so much time slinging code in VIM, I was skeptical of visual point-and-click dev. I’ve heard a lot from my peers who shared my dev background, though. They told horror stories about building and migrating Access apps. Lots of pain points.
I saw MS Access work great for a few organizations and non-technical folks. But the same as with SQL, I never actually saw non-technical people using it as intended. And I did see apps built by engineers who weren’t happy with that low-code life in the end.
No-Code Today — Echoes of the Past?
Now, don’t get me wrong, I’m no hater of no-code! Used properly as one tool among many, with eyes wide open, no-code can be tremendous.
But there’s much evidence that no-code/low-code tools never get the adoption that companies hope for. Many fade slowly into oblivion.
Migrating or maintaining these systems gets messy, as we saw with Access and COBOL. Usually, there’s little testing or docs. Moving off legacy no-code can get really expensive and risky. And some cloud-based tools may vanish in a few years!
The examples of SQL, COBOL, and Access show that everyday folks find it hard to balance power and simplicity. There’s natural tension there. The intentions were good, but adoption faltered.
No-code today seems promising, but caution makes sense. These tools should complement rather than replace traditional dev. With the right pragmatic mindset, no-code can open up tech without the pitfalls of the past. But learning from history is wise as we move forward!
Originally published on Medium.com
