Low Code Frameworks: a Dismissal and a Rediscovery

OK, I’ll admit it.

My sense of pride in my professional knowledge sometimes gets the best of me.

Or, you could call it my arrogance.

Here’s the sad story.

I think it’s fair to say that we all take some pride in the hard work we’ve done to become IT professionals. Whether it was the hard work of taking (and passing!) all those college courses (and not having time for fun!), or the certification classes we took (man, Cisco certifications are the equivalent of the California Bar Exam for complete mind-shattering engagements), or just the “time in grade” we’ve put in for all those years of just doing the work, we know that not everyone can do what we’ve done. And what we’ve done makes us…special in some way.

Which is a fine attitude to have until it gets in the way.

When I first heard of the “low code” approach to programming, my mind leaped back to the early era of HTML development. Using a text editor to code raw HTML was the order of the day. Perhaps a bit later, simple HTML “IDEs” became available, but they still required you to understand and be able to directly manipulate HTML constructs.

Then a program named “Dreamweaver” showed up. Developed by Macromedia and released to the market in 1997, it was intended to be a true website development IDE, intended to make professional web development–by professional web developers–easier.

But it quickly became the go-to tool for anyone who wanted to create a website. It was simple–drag and drop components–and appeared to be just the thing to make it possible for anyone–anyone–to create a website.

And the inevitable happened. Truly terrible-looking websites that seared the eyes with neon colors and fried the brain with blinking text and misplaced images quickly spread.

And those of us already in the IT business thought: proof once again that not just anyone can code or design, no matter how wonderful the toolset provided.

In my case, it also primed me to think that most tools, if touted as “anyone can do X with it”, were always going to be a disaster.

So, for quite some time I wrote off anything that appeared on the market that did not require effort–pain, even–to do the job we do. Sure, there are always new toolsets being delivered to the market that makes my job easier, but anything that says “so simple a child could do it” (or just hinted at that) was to be dismissed.

You probably know where this story is going.

A few years ago, after I had been hearing about this cool new framework called “Node Red” that would make defining IoT process flows simple–trivial, even–with drag-and-drop functionality and the ability to publish and exchange designs.

Pish and tosh! IoT flows are done through the grinding process of writing code–state machines, calls to APIs, MQTT queues, and the like. Nothing good can come from this “Node Red” thing. It’s clearly a toy, used only by would-be coders.

And then, one day, I was stuck on a project that required constant updating to IoT flows for a range of sensors, message queues, and databases. It was becoming quite the challenge, and in spite of my attempts at modularity it was almost more work than I was willing to do.

I don’t know what inspired me to at least take a look at Node Red–maybe desperation. Maybe the fact that it appeared to have a library of all the components I needed for the project–and a few other quite clever ones I could see using in the future.

So, I checked it out.

And became a fan, almost instantly. This thing was easy! And it supported quite complex designs fairly easily. Re-use of modules was simple and the editor was well-designed. And its UI was a web page. Cool!

After I finished the first project–one of many–I had an epiphany. Perhaps those other “low code” tools were not just for people playing at being programmers. And perhaps the time I invested in my education and the many years of sometimes painful knowledge acquisition were still needed. Sure, a non-coder could probably eke out a simple design that could turn their lawn sprinklers on and off at the right time of day. But absent a real understanding of logic and the ability to abstractly analyze a design need, the tool didn’t make a silk purse out of a sow’s ear.

Since that time, I’ve accepted that there is a wide range of low code tools available that can make my life easier, and that doesn’t remove the need for someone with my experience and ability. And, those same tools just might get someone started on the path to becoming a programmer because there is no longer the high hurdle to completing simple projects.

Win/win.

Yes, there are some downsides to low code development that have to be acknowledged. The biggest is the fear among CIOs that these tools will permit the development of shadow IT enterprise applications and systems that create security or maintenance problems that are difficult to address.

All in all, however, my journey has at least taught me that I should look past my own biases, and the marketing hype that often surrounds low code toolsets, and approach them with an open mind. If they make it possible for me to do quality work in less time and with less stress, great. If not, move on.

And it has reminded me that any tool can be misused, but that’s no reason to avoid it where it serves my needs.

So pardon me while I go back to doing some development in Node Red, and Grafana, and Influxbd….