Thinking about Low-Code’s premise in Enterprise Software Development
By: Roy Willemse
Tags: Software Development

Throughout my 20+ year career as a professional software developer I’ve always had mixed feelings about tools that allow non-developers to design and build software as capable or better as anything we could create. I loved thinking of ways to intuitively model data flows, dream up user friendly UIs to allow “power users” to drag-and-drop applications together, and in the process free up time for “real developers” to focus on harder problems. I loved to build tools like that. Yet I also felt a sense of skeptical aversion in my gut at the thought of using such tools myself.

In the late 90’s, as an 18 years old CS student living in Groningen, the Netherlands, I was building toy 3D engines in C and Assembler in my spare time, you know, like an average nerd. Mesmerized by books on graphics programming like Michael Abrash’s 1994 book “Zen of Graphics Programming”, I felt I was practicing a magical art form. Around the same time however, the rising popularity of GPUs and APIs such as Direct3D, meant that all my hard won knowledge was becoming rapidly obsolete. I remember thinking it felt like cheating — instructing some graphics driver that you wanted to draw a triangle on the display, without understanding or even caring about polygon rasterization techniques! The outrage! It appeared to highlight a generational divide among technologists, as if those who “did the hard work” somehow were more worthy.

Coding is, can be, should be in my opinion, a highly creative craft. Similar to creative writing, there are endless possibilities to communicate an idea, and many levels of elegance and polish you can strive for. How you write code, depends on more than just your ability. Is it something that will need to be understood and maintained by many? Write it as clear and simple as possible. Is performance key? Sacrifice some clarity for raw efficiency. Do you have very little time to write it? Sacrifice some quality attributes, with the intent of “making it right” another time, of course. Every approach has advantages and disadvantages, and like a chef designing flavor with heat and chemical reactions, it takes expertise to choose the best way given the immediate context.

An unflattering view of Low-Code tools is that they are more like the just-add-water style of cooking, aimed at non-chefs: you get a decent result if you follow the rules of the system, but usually you get into trouble when you try to use it for things it wasn’t designed to do. In my company for example, we’re several years underway in phasing out some 4GL model-driven-design technology. On paper it must have looked fantastic at the time, but every time I look there are new horrors to be found.

The temptation to use these tools in ways they were not designed for is powerful and requires discipline and professionalism to resist.

The people who built the software don’t think like typical software developers, but rather like advanced software users, who still need to do requirements analysis, UI and interaction design, information architecture, etc.

Where coding is required, the quality is often poor due to lack of training.

The tools tend to isolate you from the software engineering universe. That is the point, but also a problem, as it creates a specialization between non-developers and developers that ties a person’s career to the lifecycle of a (usually commercial and proprietary) product.

I’m not against building tools to enable our minds to grapple with better, harder problems. The software development universe is filled to the brim with libraries, frameworks and other “thinking tools” that do exactly that. I love the idea that something “just works”, where a tool disappears and allows you to perform superhuman tasks — because that’s what we do every day.

Abstractions of “solved problems” free up mental space to work on “unsolved problems” that require all our creativity and attention. This allowed game development to shift from a highly technological endeavor to interactive visual storytelling using amazing and free tools like Unreal Engine, for example. The “real developers”, meanwhile, keep pushing the state-of-the-art in terms of visual realism, AI, and other qualities that promote immersion in gameplay and democratize it to a large number of creatives that bring far more to the table than just coding skills.

And this is where I confront my hypocrisy, in that I, as an artisan, perhaps feel threatened by the idea of a pin-factory. Yet all this time I’ve layered tool upon tool, from the very first stick all the way to IntelliJ IDEA Ultimate, to create yet another tool to make some person’s life easier, some business owner richer, or to distract someone from the mundanities and ugliness of life by providing novel toys that hack our reward systems.

I don’t have a problem with Low-Code, seen as a reductionist abstraction (i.e. narrow application with less effort). I don’t want to waste time thinking about how data is persisted, because that’s not the problem I’m solving now. Sure I have fun with building novel database engines now and then, just like any passionate engineer. But for business software, it is largely a solved problem, and our job is to solve the customer’s problem. We need to get our heads out of distributed computing challenges (which are very interesting!) and into interactions and journeys and making tools that “just work”.

But I do have a problem with the way Low-Code is often sold — both implicitly and explicitly, as a denial of the relevancy of craftsmanship, promoting the misleading notion that very little to no craftsmanship is required at all, making outlandish promises of productivity and reduced time-to-market, framing us “traditional” software developers as the horsemen in a world ready for automobiles. Yes, any starting entrepreneur can “cheat” by using Wix to build a nice looking website, but that does not mean that they also posses the ability to effectively tell a story through content, or build a better Amazon with a few clicks. But they can learn, without being weighed down by all the things we currently call our living. We, the so-called professionals, need to stop exploiting the scarcity of technological expertise as a shield that protects our value.

We need to move on to harder things, advance the craft together. And while I’m still skeptical of using Low-Code tools in my own work, I guess that has more to do with Not-Invented-Here Syndrome than anything else. Low-Code tools will become better, they will abstract away all the stuff we don’t care to waste thought on, and allow us to build things that we think of as impossibly hard right now.