Low-Code vs. Pro-Code in RPA

Everything should be made as simple as possible, but not simpler. ~Albert Einstein

Imagine building software products without writing a single line of code. For some people, this sounds like heaven, for others (mostly experienced software-developers), it might sound like hell.

But why is that? Shouldn't a solution that simplifies work by providing an easily understandable and usable interface always prevail over the good old approach of doing all the complicated things yourself?

Well, even if the answer to this question seems trivial, this might not always be the case, especially when it comes to Robotic Process Automation. Let's dive a little deeper and analyze why the simpler solution might not always be the better one.

What Are Low-Code / No-Code Solutions?

Before looking into the relationship between RPA and Low-Code/No-Code platforms, let's define what those technologies actually are.

So called "Low-Code" or "No-Code" solutions are approaches to software development that have become increasingly popular in the past years. Those technologies provide platforms that allow users to create a software product (applications, workflows, RPA bots, ...) without being proficient in traditional software development (writing actual code).

You can imagine those platforms as drag-and-drop interfaces that allow the users to move certain components around, where each component has a certain function, and thus "plug together" a product of their choice.

It is important to note that No-Code and Low-Code are not exactly the same. Low-Code solutions allow users to add their own code when they have the need and required skills to do so, while a No-Code solution (as the name suggests) doesn't offer any possibility to write code, but rather solely consists of finished components that can be put together.

For the sake of simplicity, we're going to treat Low-Code/No-Code solutions equally throughout this article because even though Low-Code solutions allow adding your code to some degree, most of the time they suffer from the same problems and challenges as No-Code solutions. Thus, we are also going to stick to the term "Low-Code" from now on.

What Is a Pro-Code Solution?

Pro-Code simply means the conventional software-development approach. It can be imagined as a well-trained software developer writing plain lines of code, creating the design, logic, and functionality of a software product.

Similar to Low-Code solutions, pre-built functionalities still exist in the form of functions (a piece of code that performs certain actions, and can be re-used multiple times without writing duplicates) however it requires much more skill and knowledge to build and apply such concepts, than simply dragging-together components in a Low-Code solution.

Pros & Cons

Now that we've clarified the terminology, let's have a look at different areas in software development (especially RPA), and see how either of those solutions perform.

Simplicity

Creating software products is a task that requires at least a good foundation of technical and also logical expertise, no matter if using a Low-Code or Pro-Code approach to achieve your goal.

However, there's no doubt that Low-Code solutions require significantly less time-investment in learning the basics and creating the first working product.

Thus, when it comes to topics like Citizen Developers or quickly building small workflows for simple use-case, Low-Code solutions are definitely the way to go.

Flexibility

On the other hand, Low-Code solutions lack the flexibility to tightly adapt to certain, more complex, use-cases. Here, Pro-Code solutions offer the possibility to exactly create the functionality you require and add your own extensions on top of existing solutions very easily.

It has to be said that sometimes Low-Code solutions also support adding your own components, however that is usually connected to a lot of effort. It requires you to switch to a certain programming language that you might not know very well, but the Low-Code tool forces you to write components in that language. The integration process is a long and tedious one, since components have to be built, tested, released (maybe even reviewed), before you can integrate them into your solution.

On the other hand, let's say you have a Pro-Code RPA tool that supports plain programming languages like Python (a good example for that would be Robocorp ). This makes it extremely easy and convenient to extend existing functionalities with your own. For example, simply write a Python function directly in your project, and call it from your robot, without any layers in between that add additional effort.

Development-Time

How quickly you can design, build, test, and release your products is a very significant factor, especially when talking about RPA because nearly every process is an individual use-case and thus requires a new "product" (robot) that must be created.

Some might argue that Low-Code tools have a way faster "time-to-market", because of their simplicity and how fast you can "click-together" a working solution. This is true to some extent, but when it comes to really complex use-cases, the tide turns.

The problem with Low-Code solutions is that they become very big very fast. The ability to display your project as a flowchart with a logical decision tree for example, certainly helps with maintaining an overview of your project, however when it comes to identifying and fixing issues, or finding certain parts in the project, the "clicking-around" can become tedious and ineffective in large projects.

In comparison, experienced developers can navigate through their codebase very quickly and if your software-project is well-designed you'll be able to identify problems easier.

But for simple use cases, Low-Code solutions are easier to implement, thus reducing development time and of course also decreasing the costs of hiring someone to develop a solution.

Best Practices

The greatest pain we've experienced with Low-Code solutions, is the lack of proven software-development concepts, principles, and best practices being applicable to such technologies.

This starts with issues regarding repository management and source-control, but also involves topics such as the use of CI/CD for your projects.

Imagine performing a simple git diff inside a Low-Code project, where the components you've clicked together using the UI, consist of huge XML files in the background. Some Low-Code tools fortunately provide extensions and solutions for that, but as a software developer you are much quicker and more effective when using plain simple Git commands.

As stated, another example would be trying to setup CI/CD pipelines, where Low-Code solutions are honestly just a huge pain to work with most of the time. Since everything has an additional layer on top of it, which is managed by the Low-Code tool provider, you cannot have a look "under the hood" and for example re-produce the build/test/release process of the project within your pipeline, because you don't know how the Low-Code tool provider implemented such processes.

In fact, leveraging CI/CD is another inevitable thing in RPA development, since you need a way to continuously build, deploy, and test your robots in order to create a working, robust solution. For example, if you are an RPA consultant, you must be able to rely on working CI/CD pipelines to assist the development lifecycles of your projects.

Compared to the problems state above, Pro-Code solutions on the other hand are built like usual software products, or even have separate CLI tools that make it easy to control your projects, thus making CI/CD pipelines easy to build, with no workarounds required.

Control

Another common issue with Low-Code solutions is that you cannot see how the components you are using are actually built (provided that the Low-Code solution is not open-source, which is often not the case). This turns out to be a huge problem when building your products, because if there's an issue with a certain component, it is impossible for you to say what exactly causes it, and you must rely on the Low-Code tool provider to fix it.

This can become extremely frustrating when trying to identify an issue in your project, because you never know if it is your "code" that isn't working or if there is something wrong with a component (which, from my experience, does indeed happen from time to time).

We call this "black-box development", because you're putting together a set of functions, but there is no way for your to inspect the code behind such a function, so it's basically a "black-box".

Performance

Since Low-Code solutions add an additional layer to the actual software code, they often have way longer execution times.

When put into the perspective of RPA, this can indeed become a problem. From our experience, robot runtimes can be 2-3 times faster using a Pro-Code solution, depending on the use case. When a robot has a high transaction volume (meaning it is executed often), this adds up to a lot of time very quickly.

Now - What to choose?

Now we know that Low-Code solutions are great when creating simple workflows, or you are planning on educating citizen developers in your company, so they are able to build their own solutions without much knowledge about software development.

On the other hand, when complex use-cases have to be solved, or automation projects become bigger because you are trying to automate large-scale processes, then Pro-Code solutions are definitely the way to go.

It should also be mentioned that there is also the possibility to combine both approaches, which is often times a good choice to do so. For example, simple workflows that perform actions on a few different cloud tools can easily be built with Low-Code solutions. Those workflows can then be triggered by your RPA bot whenever required and the resulting data of the workflow will be redirected back to your RPA bot, which can then continue its work. This can ease development effort and enables you to combine the best out of both worlds.

Conclusion

Regardless of all that, whenever possible, we tend to choose Pro-Code tools when building RPA solutions for our clients - but why is that?

RPA solutions are often times heavily dependent on quality. A robot is expected to run without producing lots of errors in order to achieve the expected results, which in turn requires more effort put into building a very robust solution by covering lots of possible scenarios, implementing fallback methods, thus ensuring that the process continues when unavoidable problems occur, and many more things.

In the end, an RPA robot is still a software product. Thus, having available the flexibility, complete control, performance, and ability to make use of proven practices, is why Pro-Code tools are our way to go.

Thanks for reading, and if there's any feedback/suggestions, feel free to leave it in the comments.

~ Patrick