There are many good use cases for No Code / Low Code technology when building simple applications that collect and maintain records for a few simple forms. Most of these technologies include some form of a canvas designer where Citizen Developers can drop and style fields to perform basic record level Create, Read, Update and Delete (CRUD) operations.
The idea of No Code / Low Code comes from the fact that the Citizen Developer doesn’t have to write the code that maps the basic form / fields (aka the user experience or “UX”) to the underlying CRUD operations. Instead that code is often generated in the background based on a set of standard templates for each form type.
So what are the limitations of this approach?
We need to consider how the records these solutions create and maintain are being stored. For many No Code / Low Code technologies, records are added to spreadsheets, lists, or isolated tables. For most solutions, this storage is in a managed third-party cloud and not under the direct control of your organization. Whilst this is fine for smaller applications or for data gathering to enter into larger applications, it is not a great solution to address the needs of larger complex applications that contain a lot of workflow. Most No Code / Low Code approaches do not have record level access control, or extensive versioning and auditing as part of the basic functionality. Fragmenting critical business data across multiple applications (including external / SaaS) can also be a significant business risk.
At the UX level, No Code / Low Code solutions work well if the form is simply collecting the same data from the same fields all of the time without any validation. However, when we do need to start applying validation to data fields then we start needing to add some custom code (generally written in JavaScript) to the form or fields. This need for custom code increases as the complexity of the form increases.
For example, consider a use case where you have two types of an “order”, one for a service and one for a product. Either you need to create two distinct forms (one for each order type), or have one form with all possible fields and some custom code to determine which fields are displayed / enabled based on the order type. This complexity increases when considering what should be displayed as the status of the order changes. For example, how do the fields change when the order is being drafted, after it has been submitted, during fulfilment of the order, and after the order is invoiced? The form fields may also change based on the user’s role. For example, what a customer sees may be different from a sales representative, fulfilment staff, manager, etc.
Why do we use No Code / Low Code solutions?
The purpose and primary selling point of many No Code / Low Code solutions is that non-technical business people (Citizen Developers) can use them to create business functionality without the need for professional developer support and, therefore, take the load off our IT team members. The argument is that Citizen Developers are being empowered to build their own applications to fulfil their own business needs. They can do this more efficiently than bring in the formal IT team because they know their requirements and so get to true business value faster, cheaper and safer.
In all but the simplest use cases for most No Code / Low Code solutions, the emphasis should be on the developer part of the Citizen Developer title.
The reality is that to go beyond the simplest UX and CRUD functionality, the Citizen Developer is going to need some basic competence with a programming language – usually JavaScript. This means that most non-trivial No Code / Low Code applications have multiple JavaScript fragments of custom code attached to forms and fields, that will be difficult to unit test and maintain.
Although the No Code / Low Code approach is often seen as a “quick win” for the business, increasing fragmentation of critical business data and core functionality can increase the overall costs and risks of business IT as a whole.
Ironically, the idea of reducing technical debt by using a No Code / Low Code solution is instead only compounding the technical debt problem. A lot of the coded UX / CRUD functionality has been “outsourced” to the third-party vendor to generate. As soon as you need to go beyond the constraints of the application, you are back to writing more code.
This approach trades a quick, short term gain, for a large long term problem. It has increased technical debt, complexity, supportability, and vulnerability. There needs to be an alternative application architecture approach.
Like to learn more?
If you would like to schedule a virtual meeting or learn more about trellispark, please contact us and provide a brief description of your interest. Or simply drop us an email at info@greatideaz.com.