Follow us on :
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?
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.
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:
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.
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.
About the author
Bryan (33) joined Omnext about 7 years ago and in his role as Chief Commercial Officer he is responsible for business- and product development and partnerships.
Bryan primarily focusses on Omnext’s low-code propositions and advises organizations on Software Quality Assurance.