S1:E1 - Speed vs QualityFor 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.
How to get the most out of your low-code platform
The world is digitizing rapidly and this has its effect on pretty much every single organization, regardless of their size or what business they are in. The key implication and requirement is speed of change and that is something most organizations struggle with. Especially organizations that heavily rely on (custom) software to keep their businesses going. And let’s face it, which modern organization doesn’t rely on software nowadays?
One of the key challenges these organizations, and especially their software development teams, face is that the speed of change is so high and software requirements are changing so rapidly that it is almost impossible for them to keep up. As anyone who has ever been part of either a development team or ‘the business’ knows: this means trouble. Development teams can no longer fulfil business needs, confidence in new digital solutions is dropping and the business can no longer keep up with the efficiency and effectiveness of its competitors.
Fortunately, every digital problem has also a digital solution. And for several years now, the solution lies in the growing use of low-code platforms. Low-code platforms such as Mendix and OutSystems come with the promise of 7-10 times higher software development speed. This sounds like Problem solved: with low-code, development speed goes up, business requirements can be delivered faster, the development team is back on track and everybody is happy.
Unfortunately speed often comes with reduced quality and / or increased risks. There is no real use in delivering software that is buggy, hard to maintain or even unsecure now is there? In other words, we need speed and quality. The issue is though, speed and quality do not always go hand in hand and an increase in speed can come with certain pitfalls that eventually affect quality in a negative way. You must have heard of the quote: when your are in control, you are driving too slow. This might be applicable for certain business dynamics, we would not recommend it for software applications.
For example, being able to build software very rapidly also poses the threat of creating what I would like to refer to as the application jungle. Especially organizations that use low-code are in serious danger here as these platforms heavily promote business and development working together as one. When following this way of working, the business sets requirements and development starts implementing right away. In some cases, the business actually builds applications itself, known as ‘citizen development’.
Although this way of working can also have benefits, in our experience it also poses a real threat. If low-code development and its quality is left ungoverned, before you realize it to the fullest extend your organization will end up with a whole bunch of mediocre applications. Moreover the logic in your application landscape is lost and you basically lose control over your application’s quality.
So, how can you have speed and quality and hence make optimal use of your low-code platform? Well, as the saying goes: ‘All good things come in threes’.
The first step is creating quality awareness. Both business and development must be made aware that building high quality software pays out as it means that by keeping software quality up to standards:
- Your software will contain fewer bugs, which makes the users happy
- Your software will be easier to maintain and adapt, which means that new requirements can be implemented even faster
- Your software will be more secure, which will keep well… pretty much everybody happy
In other words, quality must become part of your software requirements.
The second step is quality enablement. Even though everyone in an organization may agree that quality matters, being able to spend time, money, and other resources to safeguard your software quality may be hard. Therefore, quality should be made a fixed part of your development cycle. This means that team members should also be given time during the sprints to spent on quality assurance and testing and should get the tools get objective insight in quality of the software that is being developed. If teams do not get this time in a sprint and they are told to focus on creating (new) functionality only, the balance will tip to ‘speed’ and goes at a cost of ‘quality’. If this happens, you are back to square one all over again.
The third step is providing quality support. Usually, one of the ‘quality assurance measures’ that teams take is to do manual ‘code reviews’ and tests. This on itself is quite a good thing as attention is being paid to quality. However, it also has a couple of downsides.
- First of all, these manual reviews can be very time consuming and are usually being carried out by senior team members. These team members are usually too expensive to spend their time on something like this and their expertise can probably be used for more complex challenges related to software development and architecture.
- Secondly, there are only so many hours in day right? Even the most skilled and experienced expert can only cover a fraction of the entire application in a review. In other words, he or she may focus on elements that are critical only, hence leaving a lot of potential risks left unchecked.
- The same applies to testing. Testing is a crucial part of quality control which, when done manually, can be a very time consuming and expensive exercise. On the other hand, when overlooked or willingly ‘skipped’, your software may not be in line with functional requirements and will have to be changed over and over again by your development team. This will totally diminish the speed advantage low-code platforms offer.
Fortunately, code reviews and testing can also be automated using specialized tooling. And this is the quality support that I am talking about: provide development teams with the proper tools to enable them to test, monitor and safeguard quality without making their lives harder.
How Omnext helps to get the most out of low-code
One of the tools that organizations can equip their development teams with is the Omnext Fit Test platform. This platform, developed by Omnext 10 years ago and optimized in the last 5 years for low-code, enables teams to run fully automated software analyses on their low-code applications.
During the automated analysis, the platform checks your low-code application against technology specific (for example Mendix specific) best practices and elements of the ISO-25010 guideline for software quality such as Maintainability, Reliability, Performance and Security.
The platform then offers a dashboard showing risk indicator scores which provide an overall status of your application’s quality. It also allows users to down drill and see where best practice findings (risks) are located within your application exactly. Hence, the platform offers a form of governance as managers and team leads can easily keep track on the quality of their applications, but it also provides hands-on help for developers to address potential risks and technical debt.
Want to know more? Please contactOmnext via email@example.com
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.