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.

Low Code is coming for your job.

Okay, probably not. In fact, I will argue here, Low Code will make your job easier and more satisfying. That's not to say it won't be disruptive or cause some pain, like any change, but on the whole it'll make the working lives of a lot of people better. Moreover, the companies and customers they work for will be better served as a result.

One of those traits is a need for continuity; I like to know where my next meal is coming from, or preferably, my next thousand meals. This counteracts my laziness because it impels me to produce output so that I can afford food now and in the future. It forces me to produce, but doesn't mandate that I have to spend all day producing, as long as I make enough in the time I spend working.

The other is a talent for efficiency; I see all the ways to make a small amount of work result in a big impact. I consistently hone my abilities and tools to maximize my leverage. I like it when I can take one small action and have it cascade into a whole bunch of output. I love it if I can build a tool that functions as a perpetual motion machine, churning out products without me ever having to lift a finger. I will spend hours building a tool that turns a daily five minute task into a daily two minute task. I will spend weeks building a tool that turns a daily five minute task into a once-a-month ten minute maintenance checkup.

When I say 'tool', I’m not referring to a hammer or even a better mousetrap. I'm talking about software: code. My first tools were spreadsheets; put a chunk of data in one end, get a report out the other. When I discovered pivot tables (lookup, logic, and math formulae), it was a revelation. Take a chunk of data - in my case, lists of transactions in a retail automotive dealership - and my tools could produce a staggering variety of reports. Mostly to do with profitability and pay plans, but also touching on inventory, process efficiency, staffing, and accounting. It is hardly an exciting use-case, but it's a good example of the roots of Low Code.

The reason spreadsheets are so ubiquitous is that they're powerful and that anyone with a little time and inclination can harness that power. The principle behind them, which ultimately underpins all Low Code, is deceptively simple. A piece of data goes in a box (field), some other box contains a formula that draws on that and possibly some other data, then a logically deterministic result is produced. Other fields build on this process until you have something useful.

There are two important differences between what a spreadsheet does and what the most complicated and powerful computer programs do. First, powerful programs can do more with their results. They can produce images and sounds, send emails and texts, make phone calls, link vast networks into functional systems, fly planes, drive cars, and vacuum floors. The second important difference is accessibility: a spreadsheet can be programmed with much more ease, with significantly less training and practice than any programming language. Spreadsheets are not exactly intuitive, they can't be programmed with natural language commands, but it's only a matter of hours before you are building something useful. Any programming language takes much longer to learn before it becomes useful.

Think of it this way: a programmer, working with others, can (in theory) produce every piece of useful software you've ever used on your phone, desktop, or console. However, on the first day, while a nascent C++ programmer is getting their software to print 'Hello World!', a first-day Excel user can have a pivot table summarizing sales data for a large department. If you have five years and want to build a prosperous and interesting career, go study code. If you have a week and you want to bulk up your resume, study Excel. 

Low Code does for a large number of new use-cases what spreadsheets have historically for blocks of data and reports. It makes the basic functions of a system customizable, even automatable. Low Code has endpoints including email, document generation, database entry and editing, and many others. The really powerful thing Low Code does today is tie together bespoke tools in a variety of ways. You can see this in the internal ecosystems of tools like Salesforce, Zoho, Trackvia (my personal favorite as it's where I cut my teeth), and even in the sprawling web of tools now connected by Zapier. Even all these tools talk to each other too. The closest Low Code comes to outright software development is in relational database tools. I've already mentioned some, but there are dozens of others that provide a platform to develop nearly anything you can think of and link it to any endpoint with an API.