Are you missing out on a ‘Low-Code’ revolution, or is it the wrong answer to the right question?
Updated: Apr 28
By Guy Barnes.
Low-Code is an approach to software engineering where the ‘developer’ no longer needs to know how to ‘code’ and instead uses rich graphical interfaces and built-in functions to create software applications. The benefits claimed are many, but hinge on an improved speed to market for new capabilities, and subsequently less time spent on ‘expensive’ developers.
The number of users of these types of platforms has increased rapidly in recent years with a predicted market size of $21.2bn by 2022, representing an annual growth rate of roughly 40%. This interest has driven an increase in the number of Low-Code platforms as well as a number of other legacy applications rebranding to jump on the bandwagon – remember when workflow automation tools suddenly became ‘Robots’?
But is this the latest IT fad or is it something your businesses should be rushing out to adopt? Here are some of the things you should assess if you are considering a Low-Code project:
1. Restrictions on functionality. Whilst many of the platforms are functionally rich, there is no substitute for the flexibility of raw code. Where the user interfaces (UIs) cannot create the functionality required the answer is usually to resort to - guess what - some code, in the form of an extension. This is something to be aware of, especially if outsourcing application development, because for skilled developers it is often quicker to write raw code and execute it in the Low-Code platform, leaving you thinking it can all be edited in a nice friendly UI – but in reality the UI has been bypassed – and is now of only superficial use.
2. Maintainability & Skill Set. Yes, from a business perspective, the user platform is easier to engage with than say, a pure programming platform. But when the product needs maintaining and changing, there is (currently) a much smaller skills base to choose from – especially if you need experts. That pool will undoubtedly grow but only for the platforms that have the most success - so you need to back the right horse.
3. Learning Resources. Learning resources tend to be dominated by those owned and maintained by the vendors. Whilst this is not a problem per se, it limits the ability to understand an objective solution to a problem – such as when the best option is outside the platform. To highlight, Stack Overflow (a highly popular software development community) currently has just 297 questions on the entire site for Mendix, OutSystems and Appian (three of the top Low-Code vendors) combined, whereas for C# there are nearly 1.4m questions.
4. Creating a nice UI is still really difficult. While WYSIWYG editors have come a long way, to design a complex interface using an interface can still be a very tricky or indeed an impossible problem to solve - and can lead to underperforming and clunky designs.
5. Don’t believe that you are not being locked into the platform. A common concern of Low-Code purchasers is that they will be forever commercially locked into the platform. Some of the vendors defend this by saying that the systems produce underlying code that can be executed without a reliance on the platform. This may be true, but the code that is produced is to all intents and purposes unmaintainable due to its complexity and lack of easy-to-understand commenting.
6. Upgrades, testing and backward compatibility. Don’t assume that an application you develop today will necessarily be compatible with future versions of the Low-Code system. If you want to maintain an application, there can be a large overhead in just maintaining its compatibility with the latest version of the design environment. In pure code (e.g C#), the number of ‘breaking changes’ is usually very small, and these almost always only cover ‘edge cases’. By contrast, breaking changes can be really quite common in the Low-Code world as the complexity of the systems develops.
7. Optimisation. Low-Code systems are by definition generic, which is arguably the opposite of an optimised solution. For heavy-lifting use cases such as those requiring a lot of data to be processed, Low-Code systems can struggle. Of course, there are ways around this; just don’t assume it will be an easy ride.
There is certainly the possibility that a Low-Code platform will solve these issues well enough for your particular business use case, but the increasing number of new platforms is causing an issue. Forrester reports that Low-Code platforms do have high potential, but also lists 42 such vendors. Businesses have to be wise to spot the newcomers with a good support base and the potential for longevity.
Maybe we are looking at the problem the wrong way. We know that coding in the Enterprise is perceived as ‘complex’, slow to implement and difficult to maintain, but is introducing another level of complexity surrounding the code the right way to solve the problem?
Maybe the best way to make coding less ‘scary’ is to increase awareness and knowledge of coding and modern software engineering approaches across all areas of a business. Being conversant in at least the basics will help reduce the classic barriers of ‘them and us’ between developers and business users.
Coding is now being commonly taught in schools, and in popular culture it is now becoming less of a ‘geek’ pursuit and increasingly aspirational. Across many complex financial businesses, the line between ‘business’ and ‘IT’ is blurring: for example, many mainstream business users now have an increasing understanding of languages such as Python and R, while traders often have backgrounds in computer science and are ditching spreadsheets for coding and scripts.
Ultimately, the ability to deliver capability rapidly and economically in a business is as much cultural as technical. If it appears that Low-Code will be the answer to slow delivery, maybe you should dig a little deeper before thinking it will solve your problems.