The Low Code Manifesto (Part 2)

Today, you're most likely to encounter a Low Code use-case in customization. This is where you have a tool and you want to change something in the end-user interface. Like when you have a CRM and need to make the ‘email field’ a ‘required field’ so that your front-line sales staff must ask for an email address when dealing with a new customer. You can also perform tasks like moving fields around on the user interface (UI), adding or removing them from the UI, and creating different versions of the UI for different staff. One use-case for these tasks is to enable a manager to see the ‘line time sales value’ of a customer, while a front-line salesperson can't. Then there are behind-the-scenes Low Code customizations, like having the system ping a manager when a new customer is entered into the system.

None of this is revolutionary, none of it is even rare when dealing with this kind of software. The point is that end-users, or at least the managers within a company or department, can make changes to their systems without having to call a developer. Older enterprise software offers little to nothing in this area: every screen, every transition, every field is the same for a thousand different companies using the same software: ‘one size fits all’. If you're at a large corporation with its own bespoke software tools, you're hardly better off, as the people who manage them are often equally remote. 

Don't think too harshly of the developers. I make them sound like villains, but programing is hard, and making a tool that works for a hundred different companies requires a degree of compromise. You build a tool around industry best practices and the lowest common denominator. Sometimes changes have unintended consequences, like that required email field I mentioned before that tends to create a lot of customers with an email address of 'no@email.com'. Forcing data entry doesn't force people to collect good data. Imagine being the developer, a week programming a fix for your thousand end-users, nine-hundred of whom never asked for it.

There are two key take-aways here. First, low code can be very simple, and often is by necessity. You don't want to give end-users the keys to the kingdom and have them delete the email field for forty-thousand customers. Letting people move stuff around on their UI gives them a sense of control; lets them set up their workspace for how they work, and risks very little in terms of losing or hiding critical data. Deciding when or if a customer gets an automated follow-up email can vary from shop to shop, and users can be given this autonomy without worry that they might spam all their customers with fifty emails in a day. Granting front-line users and front-line managers a bit of autonomy over their systems can give them a lot of value in both a sense of ownership, as well as genuine efficiency gains. 

Second, there is a spectrum of things we call Low Code, from the absolute minimum of moving a field around to a level just below ‘Hello World!’. Undoubtedly, people with skill sets all along this spectrum will become more and more valuable in the coming years. Further, people at the far ends of the spectrum - true coders at one end and no-code business users at the other - will also benefit.

How does everyone win in my pollyanna world? Efficiency. If you must think in terms of winners and losers, the losers will be people who insist on one-size-fits-all software with stark divisions between developer and user, and the customers those businesses manage to retain. It's possible with higher levels of efficiency that some industries will cap out on demand and have to shrink, but equally likely that increased efficiency and reduced prices will increase demand to match growth.

This phenomenon is described by “Jevons paradox”, where increasing the efficiency with which we use a product also increases demand. The most famous example of this was coal in the 19th century, when the increasing efficiency of coal-fired energy generation led some to predict a fall in coal demand. However, the opposite happened. As it cost less to run a mill or a train on coal, the number of profitable uses for it sky-rocketed. Despite coal doing twice as much work per pound as it used to, there was ten times as much work for it to do.

Jevons paradox and software are no strangers. The use-cases for computers thirty years ago were minuscule because computers cost so much. Now we carry around machines in our pockets that have an order of magnitude more computational power than the machines they used to put a man on the moon - and we use them to watch cat videos. This isn't so surprising when you realize that no one would spend billions in today's dollars, like they did on the moonshot, to create a machine to watch cat videos. It is because the computational power in our pockets is so cheap that we have found an infinite variety of ways to use it. If you believed that the only use we'd ever have for computers was moon landings, you'd assume computer engineers would be out of a job fifty years ago. 

This is what is occurring to the people on the developer / Low Coder / business-user spectrum today. We're not going to be out of a job, or even compete with each other for a static slice of the proverbial pie. We're going to grow in efficiency so that there will be more and more use-cases for us. Businesses and organizations that are too bespoke for developers to be interested in can definitely afford a Low Coder. Departments that have been under-served or bundled together will soon get their own bespoke tools. Workflows with a single user will become viable targets for customization. Finally, developers will be more in demand as the tools on which all Low Code depends will still have to be coded and customized as Low Coders demand.