The “No Code” Delusion

Change control is always a people problem re: “change control” becomes a software problem rather than a people problem.

Changes are made by people and the changes affect people. Software can help track, control, sustain. But the actual change start with people.

YAML is okay for representing a simple declarative configuration. It starts to break down when you try to encode too much operational logic into it.

If we step back, there are a few different strategies for dealing with operational logic. From least scalable to most (roughly):

1. Human processes (ex: checklist)

2. In the config itself (ex: Kubernetes' YAML)

3. A config generator (ex: Helm, Kustomize)

4. Software (ex: Kubernetes Operator)

I see a lot of people get stuck doing one for too long.

When doing one becomes unwieldy, it's time to consider the next. That or find a way to reduce the need for all that operational logic.

I can teach IF, FOR, and the basics of python in a week. I can teach ruby in about the same. For what they are going to need for a low code solution, that's enough. You don't need to teach all of programming - only a subset that would be covered in a low/no code solution.

If you don't believe this, look at how many non-CS professionals have learned VBA as their excel-fu reached a limit. Even if it's not clean to start, the natural human curiosity starts to take over.

One of the better programmers I ever knew had a high school education and was working in an airplane maintenance facility when he was frustrated with the tools he had and just started learning VBA on his own.

> General purpose programing languages are getting more expressive by the day

You know, once upon a time, we understood that declarative approaches to software engineering were superior to imperative approaches, when declarative approaches are feasible. Declarative approaches are much safer and easier to test, at a cost of only being able to express what the tool accepting the declarative approach can understand. Imperative approaches are strictly worse for any problem set where a declarative approach solves the problem within performance requirements. The additional expressiveness of languages like Pulumi is the last thing I want.

YAML is a horrible language for declarative system configuration because a) any sufficiently complex system will require you to generate your declarative codebase in the name of maintainability, b) generating code for any language where whitespace is significant will lead you to an early death, and c) stringly-typed languages are fundamentally unmaintainable at sufficient scale. But this is not an indictment of a declarative approach! It is an indictment of YAML.

> Configuration is code not data.

Data > code. Data does not need to be debugged. The best code you can have is deleted code - deleted code does not need to be maintained, updated, or patched. Code is a necessary evil we write in order to build operable systems, not a virtue in and of itself.

In my experience, "Low Code" is almost always weasel-wording. It's used to describe products that try to be "No Code", but fall short. It's a way of making excuses for everything you can't do, because you can get a "real programmer" to come in and paper over the cracks. Actually writing this code is rarely a pleasant experience, and the learning curve is a cliff that goes straight from "flowchart" to "writing React" (or worse).

As other replies have pointed out, the really successful tools are like Excel: They have a real programming language at the heart of them, and they don't try to hide it away.

Disclaimer: I founded and run something you could call a "Low-Code web environment" (https://anvil.works) - but I prefer "Visual Basic for the Web" (or "Web Apps With Nothing but Python"). We built it around the idea that writing code is inevitable - indeed, it's the best way to tell a computer what to do. So don't try to hide it - make it a first-class experience!