Despite its promise to bring much needed speed and diverse points of view into the problem-solving process, some decision makers remain hesitant or outright suspicious of low-code and no-code platforms. The three most-cited concerns are security, sustainability, and the impact these tools may have on the demand for software engineering skills.
One of the most critical and expensive issues companies face when adopting any new tool is security management: identifying, preventing, and resolving vulnerabilities. Low-code and no-code tools are no different. For some, the idea of putting software into the hands of otherwise competent employees who are not security experts is a nightmare. There’s the potential to expose critical information, the need for visibility, and finding the resources to monitor another third-party application.
Low-code and no-code tools shouldn’t be considered a “wild west” approach to building applications or workflows, however. They provide the building blocks for new software applications. If the building blocks are vetted by the company’s IT team, then anything built from those blocks will already have one level of security built in. Low-code and no-code tools do not expose raw code, and this also helps mitigate risk.
Another reason why companies may be leery of no-code and low-code applications is the question of sustainability. More specifically, what will happen when something needs to be debugged, and the person(s) who created the workflow or application lack the skills needed to do so? Doesn’t that just create a different bottleneck?
The purpose of no-code and low-code tools isn’t to completely replace coding, but to alleviate the burden that’s created when every workflow, application, and process improvement requires code. Some of these long-tail requirements can be resolved at the source, if teams have the right tools.
In terms of sustainability, the idea behind low-code and no-code applications is that software developers will have to spend less (but still some) of their time supporting these efforts. Which brings us to concern #3: How does this impact software engineers?
Impact on jobs
The point of low-code and no-code solutions isn’t to move beyond the need for software developers. Instead, LCDPs and NCDPs should liberate developers from the burden of having to solve every problem, whether or not it’s an issue with code.
For example, an HR team member identifies an opportunity to simplify an onboarding workflow within their department: the employee wants to automate the process of sending policy documents to a new hire once an offer letter has been signed.
Instead of creating a ticket for the IT team, the HR employee has access to a no-code tool that allows them to build the automation in a matter of minutes. That’s one less ticket in the IT backlog, and one more automation up and running as soon as it’s needed.
Instead of spending their time on creating this automation, the IT team can focus on more important priorities. In other words, low-code and no-code applications give them the freedom to apply their most valuable skills to the most complex problems.
The low-code, no-code turning point
What excites us most about LCDPs and NCDPs isn’t what it means for business efficiency or increased revenues. Are we thrilled about those benefits? You bet. But we also see the impact these tools will have on those who will use them:
- Teams that previously relied on software developers to solve every problem will gain more agency in their work.
- IT specialists will have more time to focus on their area of expertise.
- Companies will invite greater diversity into their problem-solving processes.
- Customers will benefit from workflows and processes that are designed by the people who know them best.
It’s too early to see all the ways in which low-code and no-code tools will change our world. As we saw with the introduction of movable type into our history, we cannot imagine what our people can accomplish when given the right tools and the freedom to use them.