Languages Professional Developers Are Driving Low-Code Tool Adoption

Professional Developers Are Driving Low-Code Tool Adoption

Regardless of which low-code tool is being employed, chances are good that the individual building an application using that tool is a professional developer. For all the hype surrounding digital business transformation and the rise of the so-called citizen developers, the number of end users that can successfully construct an application that can be deployed at any meaningful scale is still relatively few.

Most professional developers, all things being equal, still generally prefer to work with procedural code. Nevertheless, there are a lot of applications that can simply be built faster using low-code tools. Most of those applications, truth be told, are not all that interesting to build. They generally revolve around existing paper-based workflows and tasks that can be easily automated using a tablet. The only thing that is really different these days is with all the hoopla involving digital business transformation, the number of applications that developers are being requested to build has increased significantly.

Low-code tools are more expedient

Rather than allowing the application development backlog to become any worse than it already is, many professional developers have come to the conclusion it’s simply more expedient to build many of those applications using a low-code tool that automates much of the code writing process.

That doesn’t mean developers don’t look down their noses at low-code tools anymore. It just means every minute spent building a relatively simple workflow application is another minute that could be spent building something using procedural code that is a lot more compelling. Development teams could ignore all those requests for those low-level applications, but in most cases, that only results in either a “power user” trying to build an application themselves or the contracting of an external development team that takes over more and more application development projects. While that latter approach may have a certain appeal, it’s worth remembering that it’s only a matter of time before that external development team starts to want to work on projects that the internal development team would prefer to not lose control over.

Today there is no shortage of low-code tools that are made available by, for example, providers of software-as-a-service (SaaS) applications such as Salesforce and ServiceNow. At the other end of the spectrum are low code tools from providers such as Mendix, OutSystems, Appian, Skuid, and a host of others. One of the major decisions any organization makes when it comes to adopting a low-code tool is the degree to which they want to build applications for a specific environment versus ones that need to span multiple application environments.

Deeper integration with low-code tools

One of the benefits of employing low-code tools from a provider of a SaaS platform is they are more deeply integrated with the underlying database platform on which those applications are built. Low-code tools that span multiple platforms are dependent on application programming interfaces (APIs) to programmatically access data.

In some cases, however, there are providers of low code tools such as Skuid that started out providing deep integration with the underlying Salesforce database before expanding the reach of their tool to access external APIs. That approach makes it simpler to build complex applications that need to access data residing in Salesforce applications as well as on other platforms, notes newly-appointed Skuid CEO Ryan Niemann. “There’s an exponential number of those types of applications being requested,” he said.

Developers, no matter what type of application is being developed, should take their time when it comes to choosing a low-code tool. That tool may seem initially disposable, but almost every application over time becomes inevitably more complex and larger. The capabilities of low-code tools can quickly be pushed to the limit. Developers don’t want to discover where that boundary lies in the middle of a project. After all, the last thing any developer wants to be when building an application is surprised.

Latest Posts

Related Stories