No code applications are all the rage amongst fans of digital transformation. But do they actually facilitate the goal of making organizations more efficient, connected, and effective?
The short answer is no.
The longer answer is it depends on the use case and the user. There are certainly places within an organization where no code tools can add value. But the promise of no code as a philosophy is that it will transform the enterprise so that business users are free to accomplish their goals without developers.
No code applications are not capable of this, and it’s unlikely they ever will be.
No code applications by definition restrict flexibility, control, and complexity. They bundle packages of code into visual interfaces that the business user can understand and manipulate.
The plus side of this is the business user does not need a developer; the downside is if the bundled code does not meet the business user’s objectives, they either get an inferior outcome, or they need a developer to modify it.
Because business is competitive, success and survival ultimately require surpassing other organizations in performance. So even as no code tools grow in sophistication, if other businesses are using code for the same function, they will likely be doing it better.
Consider Wordpress sites. As a business user, you can use Wordpress with a pre-built theme and create a nice looking website. And this site could easily be better than sites that were coded from scratch twenty years ago.
But what do enterprises do? If they are using Wordpress, they only do so with a lot of custom code. Because that gives them flexibility and control to create a more complex website with better design and functionality. As no code tools become more sophisticated, so do the possibilities with code.
As a result, no code as a philosophy will never spearhead digital transformation. Instead, organizations should embrace yes code, and seek to use no code tools in the limited use cases where they can add value, and not assume no code meets the goals of digital transformation.
There are at least 7 different elements to consider when assessing whether a function or process can better meet business objectives with code.
How often does something need to be updated or changed outside the default settings? No code tools lock in a bundle of code, and as a business user, you have to wait for the company to update the bundles. As a result, for processes or functions that need ongoing flexibility, it is best to have coding.
I work in the software integration space, for example, and API configurations and product features are regularly being updated.
If you’re using a no code tool that wraps the configurations in a bundle of code, you lose the flexibility to update your integration the instant these changes are made.
And competitors who are coding the configurations themselves can take immediate advantage of product and API upgrades. They can also rapidly test different configuration options on their customers, which is important when discovering what your customer needs is an iterative and ongoing process.
No code tools are at their best when they replace a repeatable, relatively static process or function. So, for example, one could code an app that tracks retail employees’ timesheets and sends it to the HR and finance departments. However, if your retail business is run like most retail businesses, most likely there is a no code tool that can perform this function.
As businesses grow larger or when they have non-standardized ways of doing things, then they will likely need more customization than a no code tool can accommodate.
To increase employee engagement, for example, a large retail organization might want to gamify and personalize timesheets to the employee and their brand. They also might have a complicated internal system of classifying and monitoring employees that needs to connect with the timesheet app. In such a case, there probably isn’t a no code tool that can meet their needs.
Who controls the process or function in question? Developers are much less likely to need or want a no code tool for the simple reason they can code their own solution quickly. Developers might want a no code tool for more static, repeatable processes or functions, but if the process or function is owned by a developer, an organization should ask if it would be quicker for the developer to simply code the process than to incorporate a whole new system into their workflow.
No code tools generally have more value when a business user, like a marketer or graphic designer, owns the function or process. Tools that empower users to do what they do best — whether it is copywriters writing or developers coding — will always be most popular with users.
When you take the business process or function, how many times must it go back and forth to developers? For example, creating an enterprise marketing email usually involves a designer, copywriter, developer, and marketer.
The back and forth that is created in this process between business users and developers can slow down the time to market and interrupt a creative process. Even when custom coding results in better and more functional output, the added time in transit and the interruption to the business process has to be weighed as a potential downside of using coding.
When you use a no code tool, IT and developers can lose visibility into it. This is both because business users might use the tool without registering it with IT or even with the organization, and because the third-party no code tool might not fully disclose analytics, usage, or errors.
Using a third party no code tool, you lose a certain amount of control. You are depending on the third party to update their bundled code alongside rapidly evolving business processes and software, and you cannot necessarily influence the ways or timeline in which these modifications are made. The faster that innovation occurs, the more this lack of control can hinder progress.
A business should take honest stock of how many engineering resources are going to be required to enhance, fix, or supplement no code tools to get the desired business outcomes.
The worst outcome is often if developers have to be called in to code around no code tools. This means developers have to learn a specialized system (the no code platform) and also spend time coding, which can drain more engineering resources overall while producing a worse result than if the developer had coded it from scratch.
One way to know if a no code tool requires coding to meet business objectives is if the tool offers developer training, and if there are a number of professional developers who specialize in the system.
No code tools have a legitimate place in a digitally transformed organization. Businesses should carefully evaluate their costs and benefits, and use them when they add more value to the business than subtract. However, because code will always be more versatile, flexible, and customizable than no code, digital transformation will ultimately be driven as much, if not more, by yes code.