Low-Code Tradeoffs

I’ve been a low-code developer and architect for few years consulting clients worldwide. Even though “low-code” is a buzzword these days, the concept and its applications have been around for many years.

As it’s rather trendy today, I see that many companies great and small are tend to fit in low-code platforms for their needs. I have extensive experience working with such backend solutions in different environments and subjects areas. In addition, I participated in designing and building a new visual development platform. It all gave me an idea of sharing my best experience on this topic, and advise decision makers considering low-code could ultimately optimize software development processes in their organizations.

What is low-code?

Low-code, as the name states, is about building applications using abstractions over code to hide its complexity. This usually implies visual programming tools that make it possible to create something by combining ready blocks and configuring their interactions without traditional coding.

Such a tool rely on code generation, there’s always a powerful translator under the hood. It maps visual “low-code” representation into actual executable code, then wraps it into an deployable framework. Some of the low-code platforms have cloud integrations so they provide an option to publish the built application into a public domain.

Low-code embrace many use cases, in my post I’d like to focus on the most powerful tools that enable users to build APIs and microservices to automate complex processes from ground up.

I don’t want to highlight particular vendor platforms. Out of my experience, different solutions in this area have many features in common. All I’ll note below could be applied to a generic low-code visual tool allowing users to build pipelines and services by chaining pre-built blocks:

Where does it shine?

Firstly, I’d want to highlight the low-code usages where it really makes difference without significant tradeoffs.

• It’s great for personal use, especially if one has a little or no experience in programming. Today we’ve got a great lot of services and smart devices. Even with a moderate interest in whole variety of applications, there’re scenarios that could make life easier: from IoT shortcuts to convenient data sync between web apps.

Example: write a pipeline that parses commands from a telegram bot to append new entries to a budget spreadsheet.

• For solo developers to automate routine in their pet-projects.

Example: create a service handling orders from a single-page web shop, integrated with Mailgun API to send and track emails.

• For startups to implement a throwaway MVP in order to test a hypothesis.

Example: a travel agency has decided to start an affiliate program and now they need to implement a dashboard for affiliates to use. While requirements haven’t yet been gathered and a development team hasn’t been packed up, business analysts may scrap a simple solution using a low-code platform.

Low-code in the world of enterprise

There’s always a lot of development going on in big companies. They’re constantly seeking for ways to optimize costs and speed up delivery of new features.

Low-code may seem to be a silver bullet as it enables more people to write code and accelerates development by reusing ready-to—use blocks. This usually translates to top managers being fascinated by potential benefits of putting development on low-code track.

My opinion that it’s a popular delusion, and I saw many companies chosen this way but eventually switched back to traditional coding. Below I’ll reason it by listing the frequent issues.

Common challenges

1. As I noted above, what low-code provides us is a convenient level of abstraction above the code. It’s great for rapid prototyping or in case we’re building something that simple so we don’t need to bother about its internals. As long as we start thinking about how underlying code works, and try to adjust the visual design accordingly, we actually no longer need the low-code layer. It’s a red flag when low-code platform users explain how an application works by using terms of the underlying code.

2. It generates code from the graphical representation. A platform version upgrade may change implementation details which affect how the visual language is translated to code. It may have implications on your application behavior, and such bugs are very difficult to trace down since the platform internals are hidden.

3. Typically a low-code IDE lacks tooling for editing and teamwork because for vendors it’s hard to implement and maintain such logic when it comes to visual programming.

   • Git support is at primitive level. It goes smoothly only when there’s fast-forward merging. Other cases are tedious to resolve as even when visual graphs are merged correctly, the conflicts in components’ properties make it a mess.
   • Most of low-code IDEs don’t have “find and replace” for strings across blocks inputs. A developer should click through all the components and manually rename target value.
   • Some tools may partially provide it, but often there’s no functionality to navigate throughout the project, e.g. “Find Usages”, “Find Duplicates” or “Browse Hierarchy”. And as a consequence, it’s difficult to decouple logic as one can’t quickly jump between dependencies.
   • As opposed to no-code platforms, a low-code IDE usually provides a very rudimentary code editor to include snippets of custom code where it’s needed. The editor’s functionality is limited so traditionally developers use another IDE to write code and copy it from there. It increases effort and leads to nasty bugs caused by minor discrepancies between contents of the editors.
   • Lack of CI/CD integration in such tools is a common issue, as low-code platforms are by and large designed to be self-reliant having no perspective to participate in broader infrastructure.
   • It’s possible to continue the list since there’re a lot of rough edges when it comes to low-code development tooling. I was occasionally upset not finding any automated testing features or hot reload of a running project.

4. I watched an interview with Anders Hejlsberg, a creator of Delphi, a visual development tool that was incredibly popular along with Visual Basic at the time when I was a student. He said that “when it comes to visual programming, a line of code is worth a thousand pictures because you just die a slow death in wires going from everywhere to everywhere”. https://youtu.be/nCVNpwXijVQ (21:20)
   
   His main point was that visual programming doesn’t scale. I can’t agree more as what I’ve seen in long-living enterprise low-code projects was utter “blocks’n’wires” chaos. The use of off-the-shelf components is designed to greatly template development. But when we need a lot of different blocks with small adjustments, and we can't change their internals, we create new custom blocks, therefore generating more duplicated code.

Everything has its time and place

I love no-code and low-code platforms as they enable lots of creative people to put new ideas into practice. They start new ventures and automate everyday routine by manipulating data in a smart way.

The visual developments tools emerged a long time ago and will remain with us for a long time to come. New and more elegant products with better UX will appear. As many companies have tried to adapt low-code to their business, I consulted them along this way. After avoiding pitfalls on a few projects, I’ve gained enough experience and insight into the process.

To summarize, a low-code platform isn’t a good fit for a company where software development is a teamwork and when it has to scale. As of today, none of the tools on the market is suitable for building a full-blown service layer. Most prominent challenges include lack of professional tooling, scalability and infrastructure limitations. There’re great examples of handy low-code tools for enterprises but their main feature is that they effectively address one particular challenge (e.g., monitoring scenarios) not being platforms for building any kind of software.