Mind Matters Natural and Artificial Intelligence News and Analysis
Cardboard boxes with empty space on left side, logistics and delivery concept. 3D Rendering

The Myth of “No Code” Software (Part II)

Why (and where) no-code doesn't work

In my previous article, I noted that what programmers do is translate ambiguous specifications into very exact specifications, taking into account all of the specific subtleties that the implementation requires.

However, I recognize that those not familiar with custom software may not recognize the problem. This article describes in additional detail the kinds of considerations that cause no-code solutions to be problematic.

The essence of the problem is this: there are an infinite number of possible ways your business could possibly work, but only one way that it actually works. The work of the programmer is to make sure the software matches the specific way that your business works.

Let’s take something simple like calculating shipping. It might be easy enough to say, “Take the weight and multiply it by this number to get the price.” We could even imagine a user interface for this. You drag a line from the “weight” box to a “multiply” box, and then enter in a multiplier. Voilà!

But let’s say your shipping is more complicated. Let’s say that there is a minimum shipping charge. Now the simple “multiply” box doesn’t work. Now you must make a decision — less than this amount gets one consideration, greater than that amount gets another. Okay, well, what about box sizes? Certain things may have to be shipped in separate containers, and have a specialized shipping price. Well, then, we have to go through and pick out the items that are shipped together and calculate them separately. How are you going to write a user interface that allows that to be drag-and-drop coded? At this point, pretty much no matter what the user interface looks like, the user is just writing code.

“Aha!” you say. “But this “no code” solution has a shipping module that takes care of all of that.”

Great! But what this also means is that I am limited by what the shipping module already supplies. It may provide parameters that I can set, but if I want to do something truly novel, then I’m back to code. Additionally, to know the full extent of the implications of what the module does, you are back to needing an expert that can follow all of the subtle implications of what is happening (aka, a programmer).

Alternatively, you could conform your business practices to how the module already works. Fair enough, but the whole point of writing software is to have a custom solution that meets your particular needs. If you just want prepackaged software, you would use prepackaged software.

Perhaps, however, the software supplier adds more features to their shipping module. Unfortunately, as you add features, the complications of those features grow. The subtle interactions between decision points of configuring those features grow. At some point, the amount of configuration required and the subtlety of the interactions between those configuration decisions mean that you are basically back to coding again. In fact, now you are at a worse spot than when you are coding, because you have the limitations of having to work within the constraints of a module, combined with the problems of having to know the subtle implications of everything you are doing.

Let’s say that instead of making their shipping module more complicated, the supplier makes a separate shipping module that matches your needs with minimal configuration. That’s great for you. But now, every person who tries to use this software has two separate decision points. First, they have to figure out which shipping module to use, and then how to configure it. The whole idea of “no code” was to shield users from having to make all these decisions that come with programming. But, as the number of shipping modules proliferates, the number of decisions that the user has to make about how everything is going to work goes up, and again starts to become identical to programming.

“No code” solutions can work — they work best in cookie-cutter-like applications, or where the logic is dominated by first-order considerations. They work well when the “problem domain” (what you are trying to do) matches the “solution domain” (the parts that they already pre-built). In other words, if you are simply making variations of an existing app, or perhaps just making a mash-up of a few pre-existing tools, it works really well.  

If you want to do more than that, well, you will need code.

Jonathan Bartlett

Senior Fellow, Walter Bradley Center for Natural & Artificial Intelligence
Jonathan Bartlett is a senior software R&D engineer at Specialized Bicycle Components, where he focuses on solving problems that span multiple software teams. Previously he was a senior developer at ITX, where he developed applications for companies across the US. He also offers his time as the Director of The Blyth Institute, focusing on the interplay between mathematics, philosophy, engineering, and science. Jonathan is the author of several textbooks and edited volumes which have been used by universities as diverse as Princeton and DeVry.

The Myth of “No Code” Software (Part II)