S1:E2 - Low-code doesn't mean no-codeFor many organisations a continuous flow of application updates is crucial. This requires super-fast software development that addresses customer demand immediately. Low-code platforms are making this a reality for more and more organizations and applications. However, the speed of low-code development requires, even more than 'before', adequate QA and test solutions. The faster your figurative low-code plane flies, the more important it is to take the right measures so as not to lose altitude.
In this series Gaining Speed Yet Losing Altitude we discuss a low-code quality challenge and the measures you can take.
Beware of regular-code in low-code apps
My previous blog (S1:-E1 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:
- 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.
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
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.
Want to know more? Please contactOmnext via firstname.lastname@example.org
Visit www.omnext.com for more information
Omnext is a Valori solution
About the author
Bryan de Vries is Chief Commercial Officer at Omnext. He is responsible for business and product development and partnerships. Bryan has a strong focus on Omnext's low-code solutions and advises organisations on Software Quality Assurance.