Low-code started with ... Microsoft Office. The term became popular about 10 years ago, but it was a reality long before that.
Back in the 1990s, Microsoft Office users were creating simple, then gradually more advanced, macros and automations using Visual Basic for Applications or even relatively complex Microsoft Access business applications that connected to database systems like Microsoft SQL Server. This was my first professional coding experience, after which I learned more “serious” tools, languages, and environments at a professional software development company.
I still remember how fast we could deliver business functionality to users — in days, sometimes even hours. I experienced quite a shock when I joined the software house, where delivering similar functionality took weeks or months.
Those simple (but important) low-code applications ran on local PCs and local area networks, which worked well for only a few simultaneous users. On the other side of the spectrum, Internet apps were reaching millions of users and viewers with more complex business logic, money flows, and security requirements. Looking back, it’s obvious that low-code languages at that time were more about filling gaps between applications than creating professional Web services and APIs.
At the beginning of the century, there was a lot of talk about fourth-generation programming tools and environments, and this was really another manifestation of the need for simplicity and nonprofessional developer enablement.
In hindsight, it’s safe to say that none of these efforts were successful. But today, with a new generation of cloud-enabled low-code tools, we can finally combine the simplicity and friendliness of easy-to-use development environments with the ability to deploy distributed business applications. We can also manage them, both at the enterprise level and publicly, for end users and customers. These capabilities mark a significant shift for low-code.
Today, low-code environments provide not just simplified high-level programming interfaces and environments, but also convenient integration with various APIs: cloud storage, payment gateways, stock exchange updates, currencies, authentication mechanisms using social networks or corporate active directory, and cloud databases.
Modern enterprises embrace microservices and internal API marketplaces that expose features of all business systems of given organizations. Low-code is a great tool to meet the goal of building solutions faster and faster. These solutions will be resilient and reliable, based on proven APIs from existing microservices.
It’s easy to be taken in by the headlines about low-code growth. Let’s take a look at the main adoption challenges.
Code Is Code and Will Always Be Code
Professional developers complain that low-code is not good for large solutions. They miss traditional, proven-in-action code management tools, containers, deployment pipelines, and so forth. Too many things happen invisibly on low-code platforms, and when something goes wrong with the underlying “magic black box,” there’s no way to control it.
This also applies to basic computer science knowledge. Tons of abstraction layers help us forget about the importance of the basics, and they always resurface in the most unexpected ways. Often, low-code developers skip this part of their education and then are helpless.
One of the key arguments against low-code is lack of flexibility. If you follow the path outlined by the platform, things go quickly and smoothly. Once you try to bend the platform too much to your particular requirements, it’s difficult or impossible to achieve your goal compared to working in a standard application development environment.
There are two solutions to this problem. The best one is to have deep knowledge of the platform and adapt it to the user requirements. In other words, fulfill the requirements not by talking about additional arrows on the screen but about the user’s goal. Then propose a technical solution that will be fast and easy to implement. Sometimes this is extremely difficult because users prefer to talk about the “how” rather than the “what.”
Another solution is to take advantage of platform flexibility. There are options to augment the application with “hardcore” code, as long as the proper API extensibility points, workflows, and business rules exist in the platform.
Low-Code Citizen Developers and Shadow IT
IT departments are afraid a shadow IT organization will “creep in” with amateurish code solutions and then cry loudly for help when something does not work. There’s also justifiable fear about non-IT personnel being able to help themselves with low-code/no-code platforms faster and more efficiently than working through IT.
The answer is to adopt low-code development efforts into a larger, more consistent landscape of IT systems that support the business. This means more control over code versioning, storage, the build process, integration APIs, deployment, and security.
Security and Compliance
Shadow IT caused security issues because it bypassed IT policies, sometimes violating principal rules of data protection and access control. The same problem is common in low-code efforts with no connection to IT.
Security is a balancing act between flexibility (adaptability, speed) and peace of mind (lawsuits, company image). When it comes to low-code, it is time to work collaboratively, carefully weighing the consequences of each decision and security-enabling low-code applications.
Why Use Low-Code When There’s No-Code?
No-code attempts to get rid of code completely by using graphical tools showing the flow and data (e.g., boxes connected with arrows). However, the options are much more limited in no-code than low-code. Of course, they can work together, and most platforms offer both options.
What About Vendor Lock-In?
Vendor lock-in is another major concern for IT. Low-code development tools are often tightly integrated with the cloud environments and API ecosystems from the vendor. Many times, this fear is overblown. After all, if an organization is already using Salesforce or Office 365, for example, vendor lock-in already exists. The prudent move is to take advantage of all the available options, including low-code tools and environments.
Time is the key factor here, to the point where it supersedes fear of vendor lock-in. Startups build their solutions relying heavily on low-code and APIs; enterprises must follow suit.
Standard Code Is Becoming Low-Code
Another low-code consideration is traditional development environments like Java. In fact, the most popular Java framework, Spring Boot, is considered a low-code platform because it provides a lot of “magic” (infrastructure code) to enable developers to focus on building code that provides business app functionality.
This is happening everywhere. Simplified frameworks for development and cloud components with copy-and-paste clients for use with APIs all aim to speed up application development without sacrificing solution flexibility. Download a container with the API, which does that for you, or just enable a cloud API and use it instead of writing it from scratch.
The Irony of Productivity
Speaking of “from scratch,” GitHub and other sources provide ready-to-use solutions for almost every technical problem.
Ironically, it’s much easier to find a solution written in Java, Python, PHP, or C# than one of the low-code platforms. So once you go outside the walled garden of your lovely low-code development platform, your productivity gains may be quickly diminished by a lack of external help and the ability to “borrow” code.
This will likely change in the near future; component and API libraries for low-code platforms are growing exponentially.
[For more from the author on this topic, see “Low-Code Reality Check: Where Do Pros Fit In?”]