‘Low-code’ doesn’t mean ‘No-code’
Beware of regular-code in low-code apps
Author | Bryan de Vries
My previous blog (Speed vs Quality | How to get the most out of your low-code platform) discussed how many organizations struggle with keeping the balance between speed and quality. One of the things that offers these organizations ‘speed’ is the use of low-code platforms instead of using ‘regular-code’ technologies such as JAVA or C#. Compared to regular-code technologies, low-code platforms such as Mendix and OutSystems promise a 7-10 times higher productivity.
So, it seems like choosing low-code over regular-code is a no-brainer right? Sure, when speed is what you are looking for, it may be the way to go. However, when making the choice you should also look beyond speed. For instance, does low-code provide your development team with all the options and possibilities to realize your business requirements as regular-code technologies do?
The challenge
In some situations, the answer to this question is still ‘no’. Low-code platforms such as Mendix and OutSystems come with a lot of ‘out of the box’ building blocks and functionality which developers can use instantly yet some specific contextual requirements simply cannot be met by using low-code only.
Fortunately developers tend to become quite creative when faced with these kinds of challenges. If low-code doesn’t get the job done, they’ll fall back to what they probably already know: regular-code. In fact, both Mendix and OutSystems provide possibilities for developers to incorporate regular-code such as JAVA, JavaScript and C# into their low-code solutions. In other words, ‘low-code’ doesn’t mean ‘no-code’. In fact, when analysing the data of hundreds of automated scans executed by Omnext on low-code apps we see that over 50% of them contain regular-code elements.
Alright then, problem solved?
Yes and no. You should always try to keep using regular-code in your low-code apps to a minimum. If the balance tends to shift towards regular-code instead of low-code, you may actually want to re-consider if low-code is the correct option for you. However, when used wisely and with care, regular-code in your low-code apps may allow your developers to build functionality that otherwise wouldn’t be possible. In this sense, this addresses your original challenge.
Nonetheless, it can also pose a couple of potential new risks:
- How do you know whether or not the added code is maintainable? If there is no real insight in the (amount of) code that has been added manually, how do you know if it is of acceptable quality
- How do you know whether or not this added regular-code is secure? After all, it is not part of the low-code platform’s built-in security measures.
The solution
So, the real question is not whether to use regular-code in your low-code apps (although remember: it is best practice to keep it to a minimal when possible!). Instead, the question at hand is: How do we make sure that this manually added regular-code meets the same quality standards as set for the rest of the (low-code) app?
In my previous blog, I already mentioned the three elements required to safeguard software quality: 1) Creating quality awareness, 2) Quality enablement and 3) Quality support. These same elements can be applied here as well, but with a slightly different focus. For instance, teams that work with low-code platforms should be made aware that using regular-code is not forbidden but should be used wisely and with care. Besides that, if regular-code is being added it should also be on the radar for code reviews and testing.
Especially the latter is something that is being overlooked frequently and in fact, in most cases this isn’t even the fault of the teams themselves. It is not like they willingly disregard regular-code in their code reviews. Instead, it is the automated low-code review tooling itself that usually disregards regular-code in low-code analyses. These tools focus on evaluating the low-code model only and most of them aren’t even capable of analysing regular-code, let be imbedded in a low-code app.
How Omnext can make a difference
One of the tools that doesn’t disregard regular-code in low-code apps is the Omnext Fit Test platform. Compared to some other tools around, Omnext has been specializing in software analysis for over 15 years. In these 15 years, it has built a platform that does not only supports low-code platforms such as Mendix and OutSystems, but it also supports regular-code technologies such as JAVA, JavaScript and C#. This makes Omnext the most suited automated code-review tool out there that is capable of running analyses on applications that contain multiple different technologies all in one go.
During the automated analysis, the platform checks your low-code application against low-code specific (for example Mendix specific) best practices, but also evaluates any added regular-code such as JAVA against JAVA specific best practices and elements of the ISO-25010 guideline for software quality such as Maintainability, Reliability, Performance and Security.
In other words, it evaluates your entire application technology stack. Although the use of regular-code in low-code apps should always be kept to a minimum, at least tools like Omnext offer developers the assurance that their regular-code isn’t being overlooked and is in line with the same quality standards as everything else, making their lives and jobs just a little bit easier.
#low-code #regular-code #codereview #testautomation #qualityassurance
WANT TO KNOW MORE? PLEASE CONTACT US VIA CONTACT@OMNEXT.COM, VISIT WWW.OMNEXT.COM FOR MORE INFORMATION.
Omnext is a solution of Valori company, the number one independent quality assurance and testing consultancy organization in The Netherlands.