Every few years, a new solution comes on the market promising business leaders freedom from the need to hire technical staff. By using this piece of software, you can drag and drop visual elements into diagrams that auto-generate your code for you. Sounds great, doesn’t it?
Most programmers look down on these solutions. They’ll say visual programming is a tool for children learning how to code for the first time. Or that auto-generated code is filled with junk that slows things down and is difficult to debug. Are they right? Is it hopeless? With Microsoft, Oracle, Adobe and even Google all offering no-code software building tools, why do these concepts have such a bad reputation?
It’s tempting to assume that software engineers don’t like no-code solutions because it’s competition, and to a certain extent that’s true. Every advancement that makes the process of building software accessible to a larger group of people has experienced some degree of criticism about how it isn’t “real” programming.
But no-code solutions also highlight the problems that once only concerned programming language designers. Imagery can be so much more expressive than words. Typically, greater expressiveness in programming means more functionality and capacity for complexity, but systems built around drag-and-drop interfaces get you into trouble the second you move away from simple use cases.
Why does increasing the expressiveness of text-based languages increase flexibility, while leveraging the greater expressiveness of imagery tend to do the opposite?
The answer lies in how we construct the abstractions we program with.
Drawing the Line
It’s an abstraction, in other words. The whole point of an abstraction is to wrap a piece of functionality in a black box so that the implementation is hidden from the programmer. When you create an abstraction, you are drawing a line across application functionality. What is above that line is customizable; what is below it isn’t supposed to be.
With successful programming abstractions, the software designer should be able to anticipate what the behavior of the abstraction will be, even if the exact details of how the abstraction does it are unclear. A programmer might not know assembly, but they know that their high-level languages will compile down to a set of instructions. The user of an object relational mapping (ORM) library might not know SQL, but they understand what data they are requesting from the database and how it will be organized.
Traditional programming languages do not move too far away from the instructions they produce when compiled. The code written by the programmer is much easier to read, and it includes classes, types and functions that eliminate duplicate instructions with reusable blocks. Compiler bytecode looks foreign, but if the programmer learns how to translate each section of the instruction, they can easily trace how the abstraction maps very closely to the final implementation.
No-code solutions, on the other hand, compile down to a traditional programming language, which in turn compiles down to machine code. Often, that final implementation is not obvious. The visual aspect of these languages allows users to communicate in general terms ideas and commands that are ultimately translated to very specific terms by the code that was auto-generated.
As they say, a picture is worth a thousand words. If the vision you have in your mind maps closely to how the abstraction packages it, then no-code solutions should work well. But if what you want does not map closely to how the abstraction packages up functionality, then you may end up with a visualization that looks sensible but produces code that is filled with unnecessary branches and false starts.
How to Evaluate No-Code Solutions
So how do you know whether a no-code solution maps closely to what you want to do?
First, what’s the scale of the project? How many people will be using the application produced? Hundreds? Thousands? Millions? No-code solutions do well with smaller loads. Once you start to scale to large numbers of people or transactions, you want the optimizations you can only get by working with abstractions that stay as close to machine code as possible. Otherwise, you end up having to choose between settling for performance issues or paying more than you need to for computing resources to handle the load.
When vendors tell you that no-code solutions run just as well as custom built software, this is where the fine print is: You might need more servers or more memory for the same level of performance. One popular no-code enterprise solution I came into contact with required three times as many cloud resources to do the same job as the solution built by the dedicated engineering team.
At the same time, not every software project is aiming to serve millions of people. One example of a use case with scale appropriate for no-code solutions is rapid prototyping. Projects where you’re looking to prove a concept and don’t necessarily care about whether the application is optimized — or the code is sustainable — are a good fit, as long as you ultimately make the investment to switch over once you’re out of the prototyping phase.
Internal applications are another potential use case. Typically these applications have a fixed number of users — or at least the application will not jump from hundreds to thousands without warning. It can be difficult to justify technical stuff for internal tooling. The needs of the business side often fits the functionality of good case flow management solutions already on the market. Salesforce, for example, is not a no-code solution, but its level of flexibility and customization mean projects that look and feel like custom applications can be built on top of it.
These are examples of situations where the inefficiencies of auto-generated code don’t outweigh the benefits of not needing to hire a dedicated software engineering team. But no-code solutions might not be inefficient if you’ve chosen the tool to carefully match the project.
As you evaluate different no-code options, make a note of how often you see functionality in an example project or vendor demo that is just slightly off what you think you want. And be careful not to confuse small design elements with small changes. Those little red notification bubbles that you see on social media sites? Behind them are huge message queue systems — at least, when the feature is done correctly.
Each feature that is close to what you want but just a little off is going to be a key place for junk code. You may be able to manipulate configuration to make it look like it does what you want, while the underlying blocks of auto-generated code are going off in the wrong direction and then doubling back. Abstractions create a group of assumptions that are set in stone. If your assumptions are different, the abstraction will not account for them, and you may have no way of knowing. This can create security vulnerabilities and edge cases that trigger application crashing errors.
On the other hand, if the only thing you’d change about a sample project are the colors and branding, a no-code solution or visual programming language might get you pretty far.
Don’t Slack on Best Practices
Code is still code, whether you write it or it’s autogenerated for you. You may not have hired a technical team, but you should enforce the best practices of technical teams with whomever is building via the no-code solution.
First and foremost, have some way of tracking how your software is evolving. The easiest way to do this is with a version control tool like Git. Some no-code platforms come with version control baked in, but the advantage of the tooling favored by technical teams is that they allow you to backup to a remote code repository.
Those remote code repositories often come with tooling to scan and test code — or options to integrate with other solutions that do. Such tooling will give you great insight into the quality of the code being auto-generated. They may identify so-called “dead code” that can never be reached by any execution path of the application. Or they may highlight known security issues.
Scanners can throw false positives, though, or they can mix warnings and suggestions in with alerts in unhelpful ways. Don’t panic if they seem to return a lot of results. Look to see if there’s a known CVE or if security researchers have submitted any findings through a vulnerability-disclosure program. If the vendor runs an official bug-bounty program, you’ll likely find reports on confirmed problems and the status of a patch there.
Just as you should backup the code same as you would as if you were writing it yourself, you’ll also want to monitor the application’s performance. Most cloud hosting providers will have built in options. At a minimum, you should be tracking latency (how long it takes the system to complete a request), traffic (how many requests occur over a given period of time), errors (how often requests fail), and resource usages (memory, CPU and I/O). Remember, monitoring is not the same as analytics! These numbers are different from reports on what users are doing when they use the application.
Without a technical team, monitoring may not be very actionable. But you should know what “normal” looks like on your systems, and you should track historical data so that if and when you do bring in a technical team they have a solid place to start working.
If the no-code solution is an online platform, you might not even be able to see the code yourself, let alone do your own backups and monitoring. In that case, pay attention to what the service level agreement (SLA) provided by the vendor is. Third-party sites like Downdetector can do some basic monitoring, enough to give you a good idea whether the SLA is being violated or not.
Pay close attention to what your data export options are too. If you can’t take your business data and move to another solution, you should really think carefully about how critical the application is to your business and whether it’s worth the risk that the platform may be shut down.
No-Code Software Doesn’t Last Forever, but Neither Does Custom Software
If you decide to go the no-code route, keep in mind all software needs to be updated routinely. Just because the functionality has not changed does not mean that the application doesn’t need a refresh.
Software does not magically patch itself. Make sure you budget for a certain amount of maintenance work for the business users who built the application in the first place. Do not just dump the project on IT once the code has been auto-generated.
Quite often, no-code solutions do not save organizations as much time as teams expect them to; they just shift the investment of time from the writing of code to operation of auto-generated code. Depending on your needs, this might be a trade-off that makes a lot of sense, or it might leave you with inferior technology trying to perform critical business functions.
