Article link When is no-code useful?
At the begginning, my imagine of "no-code" was some kind of tools to emancipate productivity of engineers like me from tedious work that allowed us to get some simple functioning code pieces by click-click-click, because it seemed like a concept against "yes-code" which is what we practiced everyday.
My guess is kinda close but not all about that, later I found out. No-code do emancipate productivity of small companies as well as outliers from high cost of hiring a bunch of engineers to focus things they can export more value and realize their idea fast.
In a limited sense, no-code platforms let users develop software in a visualized and non-coding way and provide a whole encology to make the software developed usable immediately. For users, creating a software through no-code platform is merely the same as making slides. Appsheet, Webflow and Thunkable are well known examples.
We may think we may soon lose our job since builting a software becomes so easy now. However, no-code has its inherent constraints though it has many welcome shining points.
First of all, no-code software is not ready for changing, neither constraints nor development scale. As said in article "When is no-code useful?", no-code software is a great fit for transitionary, ephemeral software and high-churn code. For the former example, the prototype of an idea will be either swept into trash can or eventually put down to a well-designed yes-code software. The latter one chooses to rather build fast than evolve to catch up with changes. I have no word for that, because it indeed exploits the advantage of no-code tool that leads to high turnover rate.
Besides, no-code is work-flow based by its nature that no-code is aiming for non-engineers (who think in a humanlike way). Hence, no-code must think as human as well. This makes no-code accessible for non-engineers, easier to comprehend how to build what they want and faster to get software that not only functions but also works well. However, implemetation of no-code is limited by its nature as well since the complicate real world will not always be explainable by control-flow. No-code is suitable for some cases like OA system, but is a mess in some other cases like when you want more customizations and when you need higher information density, expressiveness, and of course speed.
We can always have more programmatic power with code than GUI platform has. The world works in this way. The deeper you dig in the domain and the lower level you are at in the pyramid, the more liberty you will gain and the stronger power you could harness.
Both no-code and yes-code have their own ecological niches that i don't think (in at least 10 years) that no-code could take place of the traditional yes-code software and in the following take away our job.
After all, "Complexity needs to go somewhere" ultimately :)
Ghost story: No code does not lead to "no coder", but AI might be that killer T_T