We all want the same thing. To build applications quicker. To maintain fewer lines of code. To spend more time solving business problems, not configuring software. But sometimes, less code is more work.
Low-code lacks when it doesn't integrate with other software. Bringing in an entirely different stack that's a black box isn't less work for engineering orgs, it's more.
— Matt Rickard (@mattrickard) August 21, 2021
Low-code means drag-and-drop interfaces to build UIs. It aims to enable the citizen developer – knowledge workers outside IT or software engineering – to develop their applications without developer support.
So what does low-code lack?
Simplified control flow. Flowchart diagrams work well for simple applications. But the expressiveness of abstractions has far outpaced this visual method of programming.
Not even the most gifted programmers can maintain this.
A low-code startup published this image to show that customers were building complex applications. Unfortunately, this is not the way. I'd go as far as to say that a few levels of indirection are enough to make flowcharts unusable for applications.
Spreadsheets do this better. Spatial data includes more information – you can address values by their row and column.
Non-serializable or versionable component. If the abstractions can't be appropriately serialized, they can't fit into a developer workflow. It's trivial to encode nearly anything as JSON, but the representation must be meaningful. The Jupyter Notebook serialization framework (and I'm a developer who likes notebooks). The JSON blob is meaningless to the version, not human-readable, and changes significantly when the contents change slightly.
A good serialization format is:
- Easy and general enough to parse by different systems
- Human-readable for portions that need to be reviewed by humans
- Similar outputs for small changes
Again, one of the most ubiquitous formats here is the Comma-Separated Values format, or CSV. What you see is what you get.
Non-declarative. Systems today need to be smart enough to reconcile themselves to the desired state. Unfortunately, most low-code tools aren't declarative, leaving users with more work to configure their application to do what they want to do. Worse yet, when users start over or want to replicate something, they are forced to repeat all the steps that took them there.
Worse yet, most of these tools don't provide the imperative APIs to get there. Instead, users are forced to go through the UI (again) and click buttons.
No API integration. Finally, these low-code tools need to integrate with internal and external APIs. This requirement isn't just a nice-to-have; it's table stacks for engineering organizations. Automatically syncing changes from version control, programmatically applying configuration, or having hooks into and from other systems are APIs that applications have to support.
What does low-code tell us? On the one hand, there aren't enough developers to satisfy all internal tools and niche applications. On the other hand, end-users are taking software into their own hands, and rightly so. But both groups – citizen developers and engineers – can learn from each other. Citizen developers can discover the best software engineering practices been developed over decades to avoid errors and run automation at scale. Software engineers should understand that these platforms are solving real business problems and creating value. It's an opportunity to design these platforms so that they don't end up as a completely different stack.