When developers shouldn’t trust low-code platforms

Low-code and lock-in often go hand in hand. Watch out for these red flags when choosing a solution

When developers shouldn’t trust low-code platforms

The application development world is continuously changing, evidenced by the analyst community’s frequent revisions of their various categories and definitions of application development tools and platforms. The rapid evolution and consequent flux are fueled by organizations clamoring for a single platform and toolset that can help them quickly deliver omnichannel, customer-grade apps spanning desktop, web, mobile, wearables, etc.

The right low-code solution based on open standards can be invaluable in an era of “more apps, faster, that run anywhere.” That said, not all low-code solutions are created equal. Here are three red flags to watch for when evaluating a solution.

Low-code red flag #1: Black boxes

Low-code gets a bad rap due to an “impenetrable black box” perception, which is understandable considering developer reluctance to run mission-critical services on something over which they have no control. The answer to increased productivity in a fast-paced environment shouldn’t be the extreme of no-code black boxes, but a low-code solution that is an “open box”—based on open standards and with a full view of the source. Low-code at its core is merely a tool whose value is derived from those who use it—and that calls for a professional developer, not a no-code business user.

Low-code for professional developers is about writing once and running across platforms, while maintaining full control over the user experience.

Low-code red flag #2: Monolithic architectures

App development was already complex. Today’s expectations include limitless scalability across multiple channels, compounded by a rapid shift to cloud-based development using containers and microservices. Development teams need to meet those expectations while maintaining focus on the user experience.

Developers are skeptical of low-code solution architectures, viewing them as antiquated, monolithic, and unfriendly to application deployment. Some of the reasons:

  • Monolithic low-code architectures can be easy to develop and deploy initially, but in the long run tend to be “tightly coupled,” making them difficult to scale and maintain. If any program component needs to be updated, this often requires large portions of the application to be rewritten.
  • Monolithic low-code architectures can be difficult to understand because they frequently have dependencies that aren’t apparent because they’re baked into the solution. With many low-code solutions, you’re saddled with trying to manage the development, testing, and production work for a monolith, minus the ability to develop, test, deploy, and scale components individually.

Low-code red flag #3: Proprietary toolsets

A plus of having proprietary tools bundled into a low-code solution is alignment of the tools and the platform, since they come from the same vending source. In theory, this should benefit developers and ultimately the business. However, the realities of proprietary tools include steep learning curves, vendor lock-in, and an ecosystem of code samples, tutorials, and communities applicable only to that vendor—all of which could be spotty or non-existent.

In some cases, a platform vendor promotes its use of standard languages but still locks users within a proprietary development process.

Besides the expense and time involved in learning and integrating niche skills, seasoned developers will likely resist a transition to a vendor’s proprietary tools. It separates them from mainstream development communities and isn’t impressive on a resumé. In addition, proprietary code can be difficult to debug, with fewer resources available to find examples and address issues.

A formula for low-code success

The inflexibility and risk of proprietary processes, proprietary platforms, and proprietary code make it clear why professional developers are reluctant to adopt or recommend proprietary tools. The ideal solution would bring the ease of low-code development to the standard tools and platforms that developers prefer, including the option to take advantage of the cloud capabilities provided by the likes of AWS or Azure or Google Cloud Platform.

Developing on a serverless cloud-based platform allows the platform to manage and auto-scale the microservices and functions. If you combine this with a Node.js back-end and a JavaScript-based front-end for web and mobile, you have a full-stack option. The benefits are manifold:

  • Combining a serverless and low-code platform built on JavaScript allows organizations to meet demand for consumer-grade omnichannel experiences using existing developer skills.
  • Different developers or even different teams can work on their portion of the application independently without conflicting with changes made by other teams.
  • Updates can be made without rewriting or redeploying the app code.
  • Code is reusable across apps and easier to maintain as functionality is isolated.

The overall result is that developers are freed to focus on app capabilities and user experience, while the platform manages the rest. The key is having a low-code platform based upon a widely-used and standardized language—such as JavaScript—that has a strong ecosystem of tools, libraries, and learning material. JavaScript even offers the ability to use a common language on both the front-end and back-end of an application, with the added benefit of enabling front-end developers to transfer their knowledge and skills to the back-end.

Open and flexible tools, platforms, and languages (like JavaScript) are good for developers and the companies that employ them. Keep that in mind when you’re shopping for a low-code solution.

Mark Troester is vice president of strategy at Progress.

New Tech Forum provides a venue to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to newtechforum@infoworld.com.

Copyright © 2019 IDG Communications, Inc.