Updated: Aug 6
For the past year or so, I have been working on a no-code programming tool called Koupi. I love to code and find that there are very few things I cannot do on a computer using programming. I implement new features, and I test them by actually using the tool. Words cannot describe how I feel when I complete a task that would have taken me 30+ mins to code in under 5 minutes.
Of course, I'm biased. And yes, I spent a year writing a tool that saves me a couple of minutes here and there. But imagine having a tool readily available, that, in just a few clicks, saved you 30minutes here and there.
I have worked for years with a lot of no-code tools. Every time I use a new one, I dislike it. I tend to say that those tools are horrible because I can't do such and such thing. However, after using them for a while, I manage to pinpoint the part that I dislike, and I find a way around it.
As a programmer, I look at those tools and think to myself: "I can't do what I want to do; therefore, it's a bad tool." I feel like it's true of a lot, if not most, computer programmers; we know everything a computer can do, and have the skills to make it happen (even though we may not always have the time).
I think it's time for programmers to think: "what can no-code tools do?" Instead of "what can't they do?"
No-code tools solve specific problems
The first thing to understand about no-code tools is that they are not intended to be exhaustive. They target a particular pain point for their customers, and they solve it. For data visualization software like Tableau and Power BI, the problem is creating interactive data visualizations. Every time I started learning either software, I mastered it very quickly. It usually gets to the point where I start writing more complicated formulas to analyze data. When I get stuck, my first instinct is to think, "this software is limiting me. Therefore it's bad." But you know what? That's not what that type of software is for. If I want to analyze data, it has to be done beforehand.
What programmers need to keep in mind when using no-code tools is that they were made to solve a specific problem, not all of them.
As a no-code tool developer, this is a hard pill to swallow. I look at the problems I experience daily with scripting, and I think to myself, "how can I make Koupi do that?" The issue is that once you solve the easy problems, what remains is the tough ones. That's when you realize that the ninety-ninety rule is a real thing:
The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time. --Tom Cargill
Programmers need to take solace in the fact that behind every no-code tool limitation is programmer trying to solve it.
No-code means less work
Let's be honest here, almost no-one likes working. If we have a choice between not doing anything all day or working all day, most of us will choose the former. So why add work on yourself by coding something that is already done for you?
Do you know who likes not doing work? Customers! That's kind of the reason they contract software engineers in the first place.
No-code tools allow "customers" to do some of the work themselves. Sometimes they don't need a software engineer to write a solution; they only need a tiny bit of help. I can't tell you how many times my "customers" have asked me to write simple code that they could have done themselves in 5 minutes using a no-code tool (of course, that's why I made Koupi).
Honestly, the same is true for programmers. We want to code our way out of every problem because we can. But the million-dollar question is: is it worth it? As mentioned above, no-code tools are created to solve a specific pain point very well. Why not take advantage of that when writing software? Why write special API hooks to various services when you can just use Snaplogic and have it working immediately?
No-code allows developers to not reinvent the wheel, and get up and running much faster than libraries can.
No-code means better planning
And lastly, no-code can, and is, used for prototyping. When someone asks you for a proof of concept, wouldn't it be better not to spend hours coding when you could use a no-code tool to create a working prototype within an hour (or even with your customer)?
The advantage of using no-code for prototyping versus a coded solution is that it allows you to walk through the logic and architecture of the product without truly developing it. At the end of the exercise, you will have noticed holes in your reasoning, areas that need improvements, and pre-requisites that would not have been highlighted by a regular brainstorming session.
Some no-code tools are particularly useful because they generate code for you, meaning that not only do you did not have to write a single line of code to get started, you now have code ready to go. Of course, there may be limitations on the code being generated, but you have a rough draft to work from.
Ultimately, no-code tools are here to stay; they're not a fad; they're a fact. The more people fight against them, the more are going to come out. It's important to see them for what they really are: another tool in a developer's toolbox. And just like any other tool, you need to learn it, get comfortable with it, and know when to use it. Just like you wouldn't use a nail gun to hang a picture in your living room, you don't use no-code software to make a full-blown application. Keep in mind that just because something is not the right tool to do the whole job, doesn't mean it can't make it easier.