No-code tools are a local maximum
This article is the second part of the “A journey towards better data tools” series and covers no-code tools and their limitations.
Spreadsheets are great for simple once-off analysis but have many limitations (see the previous article of the series).
When I transitioned from consulting to tech, I first experienced some of these limitations. I needed to access data without having to bother our software engineering team, perform a lot of cleaning on that data, and automate that process to generate reports. I did not have the time to learn to code, so I turned to a visual no-code data wrangler offered by my employer.
At first, the tool felt like a new superpower. I was able to do more advanced operations (like joins), query the databases on my own, and create data pipelines I could re-run easily with one button. It took me some time to learn the tool, but it felt less than what it would have taken to learn code from scratch.
But not everything was positive. I often got stuck trying to solve problems. I spent a lot of time navigating forums and finding workarounds to the tool’s limitations. When I looked for help from our software engineers, they could not do much because they did not have experience with no-code tools. The only thing they could do was to write some custom code for that specific problem. This meant I would have to wait until we had the capacity to implement that. Furthermore, I would also be unable to understand the code and modify it without opening a ticket to our engineering team, which is what I was trying to avoid in the first place.
The situation reminded me of my time in the trenches of digital transformation initiatives. Even though no-code has been gaining a lot of momentum recently, similar tools have existed in the enterprise for a long time (In fact, so-called 4th generation visual programming languages were a thing back in the 80s and 90s).
Even though no-code has been gaining a lot of momentum recently, similar tools have existed in the enterprise for a long time
As a consultant, I had spent many hours talking to vendors offering visual tools for different use-cases, from building an e-commerce site to automating business processes. In these meetings, I witnessed my clients’ skepticism when evaluating no-code tools and initially misjudged it as narrow-mindedness. But I quickly learned that you always encountered limitations when you dug deep enough into specific use-cases. Many of these limitations caused significant problems if not detected early on, which would leave companies with no alternative other than duck-taping a workaround. Many senior people had experienced these limitations with the tools developed in the last 20 years, and some had gotten “burned” for over-promising their capabilities. This certainly justified some of the skepticism I was seeing.
I had experienced these limitations as a consultant, and now I was experiencing the same as a user of data wrangling no-code tools. This led me to wonder if no-code tools would always be limited or just a lack of maturity that will disappear with time?
To answer this question, we need to take a step back and understand what no-code means.
What does no-code mean?
No-code tools have emerged out of frustration with the complexity of the software development process. To develop simple solutions like displaying data on a table, you need product managers to translate business needs into requirements and several software engineers with different skills (infrastructure, DevOps, etc.) to implement these requirements and ship a working solution. It can take months to implement functionality one would naively describe as “simple.” And often, teams end up re-implementing the same things over-and-over again, both inside and across companies.
One of the main reasons behind these challenges is social and technical complexity:
- 👨💼👩💼Social complexity means that many people need to agree and develop a shared understanding of what they need to build and how each member will contribute. If you ever worked in a team, you know this is by far not trivial.
- 🛠🔧Technical complexity is the same, but around how different technical components add up to a working solution. Technical complexity is also the reason why reusing software is not that simple. Whatever code you write, another team will probably have a different setup (e.g., different language, versions of a package, etc.), and reuse will likely take some time to figure out or not even work at all.
One way to define no-code is as a solution to these problems: No-code solves social and technical complexity by enabling one person to build software solutions by combining components in a standardized way.
No-code solves social and technical complexity by enabling one person to build software solutions by combining components in a standardized way.
For example, suppose you want to build an app to search for fitness classes nearby. In that case, you could do that with a few components: a table to display the classes, a map to show the locations, and a database containing the information.
Example code implementation
To understand how you would build this with code, we will look at one example. Below you will see the code to display a Google Map with a pin obtained from Google’s documentation. Don’t worry if you don’t understand what the code does; what matters is the sections highlighted in yellow. By changing the lat(latitude) and long(longitude) numbers, we can set the pin to a different location, and by changing the zoom number, we can increase or decrease the zoom level.
Besides modifying the values in yellow, if you want to get this working in an application, you would need to figure out where to insert the code fragment and send your code to a “cloud” to run.
No-code no-code implementation
To accomplish the same using a no-code tool, you would drag a component into the app (most no-code tools work in this manner).
Then, you would configure how the component works using a menu.
Let’s try to understand what are the features that make no-code different from the code we saw before:
- 👨🎨 Components: The code fragments in yellow are turned into a user interface. Instead of entering latitude, longitude, and zoom in the code, we enter the name of the location in the search bar and the zoom level using a dropdown. The benefit is lower cognitive overhead, i.e., the number of things you need to understand to make something work. If you only care about changing zoom and location, why show the rest of the code?
- 🧩 Integration framework: The map component can be easily integrated with the rest of the application without worrying about where to place the code. The benefit of doing that with code is having standardized ways of doing things, which reduces the possibility of errors and the knowledge required to integrate components.
- 🚀 Infrastructure: Adding the code to a “cloud” is something that takes a lot of expertise. There are a lot of options and many things to configure. No-code eliminates all of that, so you can focus on just focus on the problem you want to solve.
These no-code features enable users to build applications very quickly. Building an applicant tracking system or a system to book fitness classes in a gym can take less than one hour with a tool like Airtable. Many companies have spent months building similar solutions, so there are clear benefits to this approach.
But on the flip side, many real-world problems can’t be solved by combining no-code components. For example, in our fitness class search app, one may want to adjust the zoom level automatically based on the type of location typed by the user. If the user searches for a city, we will show the map at a lower zoom level to identify where the fitness studios are. If the user searches for a state instead, we show a map at a higher zoom level, which helps us understand which cities have classes.
We can’t implement the above example with a no-code solution. And this is not because it is a strange requirement. What happens is that the very nature of creating components implies making assumptions about how the component behaves. When we created our map component, we assumed location and zoom level are the inputs and don’t interact with each other. One could create a different variation of this component, but we can easily realize the number of variations grows exponentially. And this is why implementing some of these variations as no-code components may never be profitable for a vendor.
In these cases, some no-code vendors offer you the ability to solve the problem by embedding “custom” code into the tool (usually referred to as low-code). But non-technical users can’t write code, which is the problem we were trying to solve in the first place. It is clear now that no-code solutions don’t simplify code; they just bundle code components, integration framework, and infrastructure. Or, like a tech leader at a financial institution recently told me: “It is all about reusability.”
We can now easily answer our original question. No-code is solving common problems by creating reusable components, and as such, it will always remain limited.
Until no-code tools figure out how to make code easier and enable no-coders to create components out of more basic building blocks, no-code will remain a useful but limited tool, i.e., a local maximum.
Until no-code tools figure out how to make code easier and enable no-coders to create components out of more basic building blocks, no-code will remain a useful but limited tool, i.e., a local maximum.
Eigendata is a new way of working with data that brings the best of spreadsheets, no-code tools, and coding in one product. Get early access here.
