When developers shouldn’t trust low-code solutions

The application development world is continuously changing, evidenced by the analyst community’s frequent revisions of their various categories, definitions and scope of application development tools and platforms.

The state of industry flux is fuelled by organisations clamouring for a single platform and tool set that can help them quickly deliver omni-channel, customer-grade apps spanning desktop, web, mobile, wearables and chatbots.

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.

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’s 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 pro developers is about writing once and running across platforms, while maintaining full control over the user experience.

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 for this are:

• 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.

3. Proprietary Toolsets

A plus of having proprietary tools bundled into a low-code solution is alignment of the tools and hopefully 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 their use of standard languages but still locks it within proprietary development process.

Besides the expense and time involved in learning and integrating niche skills, seasoned developers will likely resist 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 tough to debug with fewer resources available to find examples and address issues.

With a view now focused by the inflexibility and risk, it’s clear why professional developers are reluctant to recommend proprietary tools.

What’s an ideal solution?

The ideal would be to have the cloud capabilities provided by the likes of AWS or Azure at your disposal, combined with the ease of low-code deployment.

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 backend and a JavaScript-based frontend 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 organisations to meet demand for consumer-grade omni-channel 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 result is 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 standardised language that has a strong ecosystem of tools, libraries and learning material. I believe that language is JavaScript.

JavaScript offers the ability to use a common language on both the front and backend of an application, and it has the added benefit of enabling frontend developers who are already familiar with its capabilities.

And for organisations moving to full stack development, they can use a full stack approach leveraging JavaScript for both front and backend development.

Mark Troester, VP of Strategy, Progress