Low Code is a potential $29 billion industry by 2025 according to a recent Gartner report, but the path of these environments will depend on two major factors; learning how to support low coders in an enterprise app dev cycle, and how to enable low coders and pro coders to work in the same code base. Done right, low code development can address the shortage of skilled professional developers and satisfy the need of business users for rapid solutions to their challenges.
Low Coder Insecurity
The Salesforce platform was the first enterprise-grade platform to support low coders. In fact, before the introduction of Apex, there wasn’t much support for professional developers. Point and click was the only way to customize (technically S-Controls provided a way of coding functionality but barely). It was simple to add custom fields and objects without being a relational database expert. The page layout editor made it possible to change the UI within limits. Approvals and workflow made it possible to automate some tasks. It sounds basic now, but it was revolutionary at the time.
One of the most important aspects of the low coder experience was the point and click setup for Role-Based Access Control (RBAC) and record sharing. This is what made the early Force.com platform a true enterprise solution. Security was built in but that is also where the casual low coder met their first challenge.
Professional database programmers understand RBAC. They understand the need to limit access to confidential information and the principles of Least Privilege Access. Accidental admins may understand the need, but putting it into practice with profiles, permission sets, sharing rules, and role hierarchies is another matter.
The first challenge for the support of low coders in your enterprise is to educate admins to understand the security implications of the changes they make, and more importantly, ensure that their changes are reviewed by someone that does understand the details. Or better yet, employ the use of an automated compliance monitoring system to detect when mistakes are made.
One Process to Rule Them All
Professional development teams learn early on that supporting multiple developers in the same code base requires sophisticated version control tools like Git that can merge changes to the same files. Imagine a world where developers check in their code and the last one to check in overwrites the changes from the developers that checked in before them. That is what it’s like for multiple low code developers to make changes in their environments and then use simple tools like change sets on the Salesforce platform to deploy into production. The last one in… wins.
Imagine pro coders using a version control system to manage their changes but the low code teams are not. How can you expect changes to make it into production safely? The key to success is for low coders and pro coders to use the same DevOps process with version control as the source of truth.
That does not mean that you should enroll your low coders into a course on branch management using Git or have them learn to perform pull requests. They may be capable of learning but they won’t be happy about it. Instead, select a DevOps tool that supports both pro coders and low coders in their preferred development environment. Pro coders live in the IDE and low coders live in their point and click UI. Your DevOps tool should enable a low coder to commit changes to a branch in Git, merge them when the changes are complete, and promote the changes through the same pipeline used by your pro coders, all without understanding the details of what is happening under the covers.
User Story is the Bridge
The final piece of the puzzle is agile planning. DevOps starts with planning and the user story is the vehicle. Pro coders are accustomed to sprint planning, daily standups, and sprint reviews. Low coders benefit from this process for their larger projects and it will help keep all the teams on the same page. Even if low coders are dealing with requests on a day-to-day basis, track their work with user stories like you do with pro coders. In fact, I recommend this even if you don’t have pro coders working in the same production pipeline.
User Stories enable you to track the reason behind the change and records the acceptance criteria for the change. In the case of one DevOps tool, the user story also tracks the actual code and metadata changes associated with the change. That minimal amount of documentation will help with user testing and provide an audit trail in the future. In a year or two, when the original requestor is no longer with the company, you will be able to answer the questions “Why did we add this field to this object?” and “do we need it anymore?”
Low code platforms are truly reshaping the landscape of enterprise development. The market forces of rising demand for developers are pushing companies to purchase platforms that support point and click development and to staff teams of citizen developers. From personal experience, this can be a great way to meet the needs of demanding enterprise business units, especially taking in this article’s recommendations.
