Introduction

Every year or so a client asks some version of the following question:

Can we use this slick low-code tool as part of our development workflow?

Invariably, a gentle debate ensues, with the following rough pros and cons:

Pros:

• Development Speed
• Accessibility
• Intuitiveness
• Flexibility

Cons:

• No code versioning
• Hard to test
• Hard to incorporate into CI/CD
• Complexity creep is hard to manage

In short, easy to get painting, but when you look up from your highly productive reverie your find that you have painted yourself into a corner.

Low Code as Metaphor

While this debate is really interesting the first time you engage in it, it tends to end up going in circles without really changing anyone’s minds. I think that this is because the people arguing against low code tools can’t really put their finger on what exactly is fundamentally wrong about point and click software development.

I’d like to argue that the debate actually hinges on attitudes to the use of metaphors in computing. My primary argument against low code tools is that they leverage metaphors in a domain where it isn’t really appropriate.

The distinction between text and GUIs

The classic text on this is Neal Stephenson’s In the Beginning was the Command Line. It’s a long, entertaining read, and Neal has since said that his position on a lot of what he discusses in the article has changed over time. But the core thoughts I’d like to extract for the purposes of this debate are:

1. Early computing regarded a computer as an information processor that you submitted instructions to, and, some time later, received some output from.
2. Because a computer can only process 1s and 0s, the most precise practical medium of interaction with a computer was text which could be deterministically translated to 1s and 0s.
3. The sole interface was an alphanumeric matrix called a KEYBOARD, which you can use to enter plain text instructions which you submit for execution, and/or save in human-and-machine-readable files for later use. You may have the convenience of a screen to see what instructions you are submitting, but it’s not strictly necessary.
4. In the early 80s, smart people realised that they could make computers much more accessible by introducing a mediation layer between the human and the computer.
5. This mediation layer employed several new interfaces (some physical, some virtual) to enable the use of METAPHOR in the transmission of instructions between humans and computers. Think mice, desktops, folders and windows.
6. You need a screen and a metaphorical space to observe and manipulate. This tight coupling of hardware and virtual space is the primary interface, and it is a canvas for the production and manipulation of metaphors. It can be supplemented by a (metaphorical) spatial navigator called a mouse and a keyboard. We call this collection of metaphors the GRAPHICAL USER INTERFACE, or GUI.

Now, the introduction of this new mode of interaction with computers resulted in benefits which look a lot like the pros for low code tooling:

• Much faster speed of interaction
• By using metaphors which evoke things humans are already familiar with, you can make computing much more intuitive and accessible
• Metaphors are only really limited by human imagination, so you have ultimate flexibility in what you can do with a computer (from an ergonomic standpoint). All you have to do is (a) conceive an accessible metaphor and (b) map the implementation of that metaphor to computer instructions

The metaphor is not the thing

Now, the GUI unleashes fantastic power. We are able to do things with a speed and dynamism that is simply not possible without it.

However, the metaphor is not the thing. When you are typing a letter in Microsoft Word, the letters punch on the keyboard appear on the ‘page’ in the window on the screen, but actually this is an illusion. When you save that file, you are not saving regular plain text to the hard drive. You are saving a whole lot of binary (non text) data to a file that contains all sorts of information (including formatting, comments, revisions and, yes, your words). If you try open that file in another program, like notepad, you’ll just get a whole lot of gibberish.

Granted, you might argue that plain text is also a metaphor, but I would disagree, because the mapping of ASCII or UTF-8 to machine code is so stable as to be practically the same thing.

Low code tooling makes heavy use of metaphorical computing to improve the ergonomics of a computing task. Instead of the SQL text representation

SELECT id, age 
FROM names
LEFT JOIN
ages
on 
names.name = ages.name

you are simply ‘dragging’ an ‘arrow’ from the name ‘slot’ of the names ‘box’ to the name ‘slot’ of the ages ‘box’. This is both faster and more intuitive because it leverages metaphors that have well worn analogues in the real world.

So what is the problem?

So far, there isn’t really a problem. We’ve gotten faster, more flexible, and more intuitive. Issues only become apparent when we realise that the mapping of metaphors to computer instructions are heavily application specific, and mutable.

By mutable, I mean that a GUI operation can actually evolve over time. Dragging an arrow from one box to another will generate radically different code across software versions. This is how software adds new features. Sometimes the application developers realise that their whole codebase needs to be rebuilt from the ground up to keep up with consumer needs. This is how we go from .doc files to .docx files.

The sheer amount of code required to map a metaphorical operation to a low level instruction is mind boggling - far more than can be easily parsed by a human looking at what has been done. Mapping these operations from one application to another is similarly complex, and maintaining backward compatibility of your GUI operations is a significant, often impossibly expensive challenge for the people who provide your low code environment.

Microsoft Excel is not the universal tool it is because it makes mathematical operations easy via a low code interface. It is because business owners have a high degree of certainty that their Excel files will be openable, modifiable and executable year after year, version after version. This commitment from Microsoft has cost millions of engineering hours and billions of consumer dollars.

Two implications of the many levels of abstraction between a GUI and machine code are:

1. Facilitating portability is very costly.
2. Introspection into operations is very hard.

You cannot be sure precisely what dragging that arrow is actually doing, and even if you could, tracking how that changes over time in a human understandable way is really hard.

Sure, you might say that programming languages change over time, but the fact remains that programming languages are languages - you can learn them, they are semantically meaningful, and you can read a dead programming language, reason around its intent, and capture that intent in another programming language. This is not the case with a binary file format opened in a text editor. These representations are fundamentally not meant to be understood by humans (or other applications).

Just enough metaphor

So, the key question we must now ask ourselves is how much metaphor are we willing to tolerate?

I have found that the more responsibility someone has to keep the code working over the long term, the less keen they are on using low code tooling - with the exception of developers who totally identify a business activity (think CRM) with an application (think Sharepoint). That is to say, if you think CRM == Sharepoint, then naturally you prefer Sharepoint tooling (low code) to whatever actual text based code sits under Sharepoint.

The reason for this, I suspect, is that portability and introspection don’t really matter to you, so you might as well get the benefits of a GUI. You’re not going to need to transport your CRM to anything else, and you don’t need to look at the low level code because that is not the level of abstraction at which you operate. As long as your metaphorical ducks keep quacking and swimming (as opposed to falling over of suddenly mooing), it’s all good, and you pay good money to Microsoft to ensure that the veil is never pierced.

However, if you care about portability and introspection (think ability to jump platforms, unstable vendor landscape, no control over license fees, ability to see exactly what junior dev X did before the site crashed), then you really, really want as little metaphor as possible. And it just so happens that writing code is one area where those two characteristics are of paramount importance. All the traditional objections to low code tooling arise from this sensibility.

Firstly, in a professional context, code quality is heavily associated with test coverage. You want to be able to comprehensively test your code, because there are so many developers touching it, often with very little time to think deeply, that you want intended consequences to be caught through testing. To do it well, you want to automate that testing. And, when the tests fail, you want to be able to isolate what has actually changed and identify why that exactly causes the tests to fail. How many times have you seen someone throw up their hands and say, “the spreadsheet is broken”? When that happens, you have to review every cell until you find the error, and even then, you can’t be sure it’s the only error. Good testing tells you exactly which cells are broken, and why.

Secondly, you really want to know that your code, when executed, will behave the same way every time. With low code tools, you rely on the engineers at your application provider to make sure that the metaphor web that you call your data pipeline behaves exactly the same way as it did in the last version. Often that is initially the case. But, over the years, these can change in subtle ways, and then you’re stuck with impossible to detect, can’t put your finger on it issues than you can’t resolve.

Thirdly, text is portable. You can open an ASCII or UTF8 text file on any operating system on the planet. If you have the right compiler installed, you can execute that file on any operating system on the planet. Files associated with low code tooling only make sense in the context of that application and to make matters worse, that application (because it itself a metaphor on top of the metaphor of the operating system GUI) only makes sense in the context of a particular version of an operating system, which sometimes only makes sense in the context of certain hardware.

Granted, so many engineer hours have gone into stabilizing hardware and operating system conventions that this might seem a bit hyperbolic. But consider that most large organisations are running critical code written 20 years ago. A C program written on Windows NT probably works just fine on the latest version of Android (provided it isn’t running a GUI).

Finally, with text, you are able to actually monitor the complexity of your application. You can literally look at what the code does, and go for a walk, and think about if that’s the best way to do it, and come back and write it in a more elegant, concise or general way. And I think that’s worth quite a lot.

So, yeah. How much metaphor are you willing to tolerate? To use my computer to play audio files streamed from a music service or to organise pictures in my photo albums, sure, heap on the metaphor - whatever makes it as easy and delightful as possible.

But - when building data pipelines, or creating business critical process automation - give me plain text every time.