Have you come across the term "No Code" before and wondered what it meant?
The term itself is quite strange, I mean imagine selling another product that's linguistically structured this way like an architect selling "no blueprint" or a lawyer selling "no contract" or similar. Putting the grammatical weirdness aside for a moment this term does tend to refer to a very specific type of product offering.
What is "No Code"?
"No Code", note the capitals, is another example of a new term being used to sell something that is not even remotely new. People have been looking to make systems that are configurable by end users literally since the very beginning of the automation industry. Configurable software has existed in various forms from the beginning of the computing industry. This is because instructing the machines to do something useful can be done in a few ways, you can write software that will get the machine to do things and you can also create configurations to drive existing software to do useful things. Enabling power users to have enough flexibility with software to effectively do their jobs has always been a crucial part of making business software.
As many people have commented on over the years there's no clean boundary between code and data. In fact some of the most powerful programming paradigms mix both with code as data and data as code. In a business setting configuration scripts/files and a variety of domain specific languages cross exactly this barrier.
Perhaps the most mainstream example of this is Excel spreadsheets. There is not a clear distinction between where the data and the code is stored in these. There clearly is enormous business value in spreadsheets even if they aren't neatly categorized as programming. Despite their widespread use, nobody called spreadsheets a "No Code" solution as spreadsheet software greatly predates the usage of this term. Microsoft Excel was first released in 1987 and the term "No Code" has only come into wider use in the last 5 years, even 10 years ago I don't remember hearing this term at all despite working on something that could now potentially be called a "no code" solution 1.
My somewhat cynical take on the "no code" branding is that it is changing the mental associations of using a GUI to do useful business tasks and trying to cash in on the perceived benefits of writing software. The idea is that mental associations with hiring software engineers is expensive, because software engineers generate a lot of value and hence attract what is seen to be high wages. So the organization that needs to create software but doesn't want to hire software people faces a dilemma. Here's where the sales genius of the "no code" solution comes in, "no code" solutions are effectively a way to start introducing the power of software creation to organizations that are attempting to avoid software creation for whatever reason.
What's the sales angle here?
Today I was having a good conversation with someone I know in the industry about the challenges of selling products in the automation space. There's this mental distinction that people have between being users of software vs creators. Not every organization wants to be in the business of creating heavy software engineering code, which to be clear I think is completely reasonable. But what makes things complex is that the trend of "software eating the world" has meant that more and more people are exposed to computer software at work as each year goes on. As time goes on the nature of some work changes, a hundred years ago professional statisticians wouldn't have been doing work with software but now all professionals in that area are using computers extensively and many have coding abilities at a rudimentary or higher level. This trend has been seen in a surprisingly large number of professions. Not to mention the extreme proliferation of computing devices in day to day life, a huge number of people now carry in their pockets a computer more powerful than the Apollo space program: a smartphone. People know that software is increasingly becoming a crucial part of remaining profitable and the events of 2020 have made this even more apparent for many, but taking the step into explicitly hiring software staff is a tough one for organizations to make.
It's a bit strange for a product to be named using a negative but this really gets at the spirit of "no code". People know at some level that computers are the future and that they inevitably will have to use them more but people are fearful of this. To sell something as being not code is to try to tap into the fears that people have about code and the people who would create code. At some level people know that using technology will be an important thing for the future of their organizations and there's a fear of missing out at play.
There's often a sense of fear involved in many "No Code" related decisions. The negative in the name is indicative of the entire mental framing around these products, one that unfortunately tends to focus on fear.
A lot of companies and organizations fear code, and potentially for good reason too, implementing code based solutions is hard takes a specific set of skills. Many software engineers say that "code is a liability", this is because if you have any sort of service that requires code to run you have to deal with issues of maintenance/security/updates/etc. When the code base gets larger it tends to also get harder to understand which in turn increases the amount of time. This is likely to be taken completely out of context by the sorts of people peddling "no code" solutions because they can easily create a straw-man where they say that are removing this liability by removing the "code" but really this isn't even remotely true. What "No Code" really does is just creates a low-barrier to entry system for people to do programming in but it doesn't remove the ongoing costs of the system and in many complex cases these cost are usually higher than doing it with code.
You'll probably notice that if organizations are not fearful of code, and technology more broadly, they will almost never use the term "no code" to describe what they are doing, they will instead talk about things like: automation, configuration, user experience, user interfaces, customer experience, etc. All of these traditional approaches can better meet the requirements that "No Code" platforms target given the right people.
What is being "solved" in a no code solution?
In a world where more and more work is done with computers the ability to get those computers to do what you want is very useful.
Despite this many organizations do not want to hire software staff because software staff are expensive.
Software staff are expensive because they can provide a huge amount of value to organizations and thus demand for skilled software professionals is extremely strong worldwide. So if you want to get highly skilled software staff you simply have to fork out money, if you make the right hires then this is money that's extremely well spent. It's really hard to make good hires for a skill set your company doesn't have, whatever that skill might be. So if you are a non-software company you run into the issue where it's hard to hire software talent2.
The temptation is therefore strong to try to procure "solutions" that can provide some value without having to hire software staff.
To be clear this is exactly the right strategy for many organizations, should a small non-technical business3 go and hire a team of data engineers to create a customized data platform for the data science team instead? No, they clearly aren't in a position to do this and using something off the shelf is probably the best option because it's the only feasible option. Many small non-technical businesses simply don't have the cashflow to hire a large team of software engineers. On the other hand a large organization that's dealing with missing critical data most certainly shouldn't kludge together a solution in Excel because that can lead to disastrous consequences as we saw in the UK lately or just poor business processes like the organizational anecdote I described in my article about RPA. Getting the right tooling in place for an organization makes a huge difference and what is "right" depends a lot on the scale at which the company is working at. Process improvement software tends to be the sort of thing that multiplies the output of a firm by some amount, but small businesses can be in the phase where additive gains are far more important than multiplicative ones. A good consultant in this space should be able to judge what is best for the organization in this regard.
Something I've encountered many times is the suspicion that the negativity from software engineers towards "no code" platforms is just related to the bias of these people wanting to make sure their jobs aren't destroyed. I think there may be a slight bias in that regard with some people, but most experienced software engineers are already extremely used to "automating themselves" out of a job already as this is an explicit goal of many end-user facing software interfaces. Modern software practitioners already reuse large amounts of existing work, whether that be commercial off the shelf products or software libraries or APIs. In 2020 you simply cannot be competitive in many areas if you don't leverage external software solutions in your organization, what you do need to be sure of is not outsourcing your core competencies. I think it's especially revealing that despite the high cost of software staff the largest tech companies, who are entirely capable of making a "no code" platform in house, tend to keep hiring people who have "coding" as part of their job skills at extremely high salaries. This is because entering in code via programming still remains the most cost effective way to get computers to do many tasks, hence the reason quality4 software engineering staff are still in exceedingly high demand despite their high wages. All of the biggest tech companies still hire large numbers of software staff because this allows them to make tooling that exactly fits their business's needs and I think their actions really speak for themselves in this regard.
If you are looking for help in making these strategic decisions for your organization please get in contact with me over at linkedin or via email (consulting at lesinskis.com)
A project I was involved in years ago was making a domain specific language so that power users could interact with a simulation system engine by running the queries they wanted without explicitly needing to learn how to program. The way this worked was that the users could keep using Excel but they could do some more powerful commands in the cells. So instead of being limited to doing simple things in the spreadsheet cells like
SUM(A1:A4)or similar they could do things like
IMPORTANT_BUSINESS_FUNCTION(B1:B5)which saved them a ton of time and effort while making much more powerful data analysis available to the organization. This meant that the questions they needed to answer could get answered without having to upskill all their staff to be programmers. ↩
Feel free to get in contact with me if you want to get help with hiring, I do offer hiring help consulting. ↩
I'm defining small as a business with less than 10 staff and "non technical" as an organization that's primary output is not technology. ↩
Software skills don't distribute themselves in the same manner as many others, the best engineers are many multiples more profitable than the average. Steve Jobs has an interesting observation about this in this interview. ↩
This post is part 5 of the "AutomationAndRPA" series: