May 21, 2024

NoCode Will Not Bring Computing to the Masses

NoCode, scripting vs applications, and software marketplaces

No Newsletter next week

I'll be giving my conference talk at DDD Europe.

NoCode Will Not Bring Computing to the Masses

I don't have a whole lot of time this week so here's something that's been on my mind a little. I haven't researched any of the factual claims; consider this more some incoherent early-stage theory.

Define a "NoCode" tool as "any tool made to help people without any programming experience do things that normally require programming." Most software engineers have a very dim view of NoCode, mostly because the primary way SEs interact with it is to clean up the messes left by overly ambitious nocoders. I don't think it'd be controversial to say there's a wide variety of problems nonprogrammers should not try to solve with NoCode tooling.

On the other side of the spectrum, there are a lot of problems that are trivial to do if you can program, and impossible without it. The canonical example I use is "upcasing a string"; others are "find strings of digits in a document", "figure out each student's average score across several tests", etc. If you don't know how to program, you either have to find someone else's program that does this thing or do it manually. This is where I think NoCode has real potential to help the average computer user: it can let them do simple programming tasks without having to learn all of programming first.

The goal, then, is to figure out what defines the space of "trivial for programmers, impossible for regulars". I think a good first-metric would be "equivalent lines of python". If something can be done in L=10 lines of not-very-clever Python then it should hypothetically be nocodable. If it takes H=50 lines, it definitely should not be. In between is a grey area. These numbers are just off the top of my head; finding the real values of L and H would require a lot of research and user examples.¹

NoCode adapted to this space probably wouldn't be that profitable, but it would do the most good for the most number of people.

"The most good" will do the least good

I wanted to talk about some of the consequences for NoCode design, but couldn't figure out where to start, so did the wise thing and took a walk. On the walk I realized that no matter how much a tool empowers the user, almost nobody will use it.

Proof: how many programmers have iPhones? How many of them use Shortcuts? I mean, I have Tasker on Android, I know how to use it and have used it in the past, and still I regularly don't use it.

It's not enough for a tool to solve your problem for you to use that tool. You have to also A) recognize the problem you have is solvable, B) recognize the tool can solve it, and C) be reasonably confident that you personally can solve the problem with the tool. You need knowledge, skill, and the right mentality. Even programmers, who already have that mentality, don't automatically generalize it to all applicable domains. Otherwise we'd be doing a lot more with our phones.

It's unreasonable to expect the average person will use any NoCode to solve their problems, regardless of how easy the tools are. This leaves the people for whom it provides economic value, which is why all modern NoCode tools are oriented towards business.

Do people want grey markets?

There's two exceptions to this rule I can think of.² The first is Excel/GSheets, which we do see regular people pick up. I'd venture this is because "very simple data organization" and "semi-complicated math stuff" is a common enough thing enough people need. Maybe also they have gentle on-ramps: you can solve basic problems while knowing very little. Finally, there could be a social aspect; everybody already knows about spreadsheets, so it's not as big a jump to start using them.

The other major exception is that I've seen a lot of people who do use tools like Shortcuts and Tasker… as consumers of other people's published automations. These tend to look more like "scripts" than "applications", suggesting that our official marketplaces are designed to deliver applications, but people also need scripts.³ The NoCode gives them a "grey market" they can use to install scripts without using the official heavyweight channels.

One negative consequence of this is that any widely-used NoCode also becomes a potent vector for malware, because the people who are running scripts are ill-equipped to audit them.

Ok, I checked the code and it said (and please bare with me here):

-If flibbity is frabjous, zibble wobble at 42% and blippity blop playlist; otherwise, schnoofle Grobber Mode.

SOMEBODY HELP — source

---

Trying to pull all of my thoughts into something coherent:

1. People need scripts.
2. NoCode can make scripting much easier.
3. Even if NoCode makes scripting easier, people won't actually write scripts.
4. What people want is to be easily able to find and run someone else's script like they do an application.
5. NoCode could make finding and running other people's scripts easier, too.
6. Doing so is potentially very dangerous, as people aren't able to evaluate scripts for safety.

If you're reading this on the web, you can subscribe here. Updates are once a week. My main website is here.

My new book, Logic for Programmers, is now in early access! Get it here.