Part of:How AI and low-code development are shaping DevOps
What IT pros need to know about low-code limitations
Low-code environments promise to simplify and speed up software development, but their limitations can create challenges for enterprise IT. Compare models for low-code adoption.
Low-code is a development approach that relies on automation and abstraction to simplify the software creation process -- at the cost of the customization available with traditional programming. But do low-code's limitations make it a bad strategy for enterprise IT?
Low-code development is based on tabular specifications or drag-and-drop features, which limit what low-code applications can do. In most cases, low-code has a specific set of template applications, the most common of which is select-and-report.
Because low-code platforms make software development easier, so-called citizen developers can use them with no programming training or skills. However, professional developers can also use low-code tools, though they don't offer the full spectrum of programming techniques available with true programming languages.
Citizen developers use low-code to offload simple projects from IT staff. There is little or no IT involvement in project selection, code audits or developer support.
Citizen developers use low-code, but IT staff are involved in project selection, code auditing prior to use and supporting citizen developers.
IT organizations use low-code for simple projects.
The most common low-code limitation is a presumptive application structure. Almost all low-code tools have a limited number of application types, such as select-and-report, summarize-and-report or match-and-process. The low-code developer can then fill in details for the selected model. While this takes much of the routine file and record handling out of the developer's hands and reduces programming time, it also constrains the application's capabilities.
A related limitation is reliance on drag-and-drop or tabular functionality specifications. Low-code relies on functions rather than instructions. These can sometimes be applied by dragging a function block into place in a flow diagram or specifying actions in tabular form -- a popular report-and-display creation strategy. While some tools enable programmers to create functions for use by low-code developers, the lack of general programming language capabilities limits what can be done with the data.
Low-code application performance is almost always noticeably poorer than software developed in a true programming language.
In addition, low-code applications sometimes require major changes to accommodate what appear to be minor refinements in requirements. This is true when a different application model is mandated because of a specification change. In some extreme cases, a seemingly minor change could be impossible to support with a low-code tool because there is no corresponding application model or code feature to support it.
Use-related low-code limitations
Poor application performance and resource use is a common complaint about low-code. Low-code application performance is almost always noticeably poorer than software developed in a true programming language.
This problem is most acute when the low-code application must handle a large number of records, is run regularly over a long period of time or both. This means that enterprises running low-code applications in the cloud can be hit with unexpectedly high cloud charges.
Low-code development can also lead to errors not caught by the package and that then go undetected long enough to waste time and resources. For example, a low-code select-and-report application might have criteria that select nothing or create invalid data due to a programming error. Most low-code products do not impose testing and release discipline on developers, and citizen developers don't always understand how to apply these disciplines on their own.
Low-code and traditional development aren't necessarily opposed to one another -- each approach has its own use cases and benefits.
Compare low-code adoption models
The first model for low-code adoption -- uncontrolled citizen developer involvement with low-code tools -- is risky, as it's likely to be affected by all the limitations listed above. The second model -- IT-moderated citizen development based on low-code -- can readily overcome all those limitations.
The key is for software professionals to qualify, audit and support low-coders. Consulting firm CIMI Corporation's research found that enterprises say a single professional can support between 30 and 100 low-coders. This more than justifies the investment in resources through improved project turnaround and a better relationship between IT and line-of-business organizations.
The third model -- use of low-code by IT professionals -- is a bit more problematic. Professional programmers can, of course, create a traditional application using a modern programming language, but adopting low-code can speed up simple application development. Given the limitations of low-code, however, this might not be enough of a benefit to merit adoption.
Development organizations' views are mixed on this issue. About half believe that it's better to use low-code tools to free up developer time, whereas the other half think that developers should use "real" programming tools and techniques, according to CIMI Corporation's research.
Because there are merits to both positions, it's often best for enterprises considering either the first or third low-code model to instead converge on the second. Too much reliance on developers can be as bad as too little. If the goal is to speed up simple application development and save developer resources, shift to a model where line-of-business organizations with proper IT support can develop their own low-code applications.
