[the_laka]

Low Code and No Code platforms transform the whole premise though. They do make it easy to "show it how to attach a fastener, then walk away".

Too bad, as developers, we scorn those platforms instead of improving them to the point we'd be obsolete.

[hyperman1]

In my experience, Low Code tries to fix the non-problem and makes the real problem worse. They will get you up to speed fast, but with a much lower output plateau than normal programming tools. Some experience from one low code tool I used this year:

Non-problem: Writing code. This is the easy part. COBOL took typists, gave them a week of courses, which made them successful basic coders. Low code helps the most basic junior but slows down the average coder by forcing everything trough drag and drop.

Problem: Reading code. Most low code platforms I've seen show you only a small part of the code, needing a lot of clicking around in a GUI to make sure you found it all. It either transform it in a mess of arrows and boxes or spread it out so wide you spend more time scrolling than reading. I've found myself reading the XML dumps of our current tool just to spare me some time.

Problem: One size fits all. You can't polish or finetune the standard components. What you see is what you get. This guarantees you both a minimum and a maximum level of quality. Yes, there are escape hatches. No, they won't help you. You will make parts of your program unstable or less user friendly because your low-code vendor didn't foresee all of your needs.

Problem: Versioning. Boxes and arrows don't merge well. There is generally only a small team working on 1 piece of code. You can't scale it past 3-4 people. Also, emergency fixes in prod don't easily propagate back to dev, especially in a high-stress situations. You'll have to do it manually. This almost guarantees regression bugs.

Problem: Searching code. If you have enough code, the day comes where you'll need to find all references to something. I've grepped code bases of >10 000 000 lines. Can't do it in more than the most limited way with low code.

Problem: knowledge exchange. Something like stack exchange works because you can type text. Print screen is the only option available in most low code tools.

As the saying goes, the core of ICT is not programming but Information and Communication. If you want to make programmers obsolete, you need tools that help you organize information and ease communication.

Low code is simply the wrong way to look at the problem. it ends up throwing tons of man-hours at a problem. In the long term, it creates more programmer jobs, not less.

[stdbrouw]

But that's exactly what people used to think in the 60s and 70s: instead of requiring a bunch of electrical engineers to build some arcane contraption, now ordinary folks can just write something that almost looks like English and you can automate anything and do calculations in seconds that used to take months! If that didn't pan out even though it seemed so freaking obvious that it would, why will No Code be any different?

[bildung]

To add an anecdote: No Code already was the hot new thing in the 90s when I studied CS. You could click together custom interfaces in Delphi and even do basic wiring with clicking alone, IIRC. Devs expected that laypeople click together the solution they want and developers do the remaining wiring. Yet no non-developer could actually use that thing. Nowadays I think the main hurdle is the transformation of a fluffy real world problem into something of an algorithm. Developers do this almost unconsciously, because they practice this all the time, and thus are usually not aware of it. Yet this process of quantification of the real world problem often is the actual problem, not writing it down as code.

[carbonguy]

> I think the main hurdle is the transformation of a fluffy real world problem into something of an algorithm.

I came to a very similar conclusion after I had been teaching programming in high school for a few years: the difficulty of "programming" is in learning to think algorithmically, and no amount of "No Code" tooling gets you around that problem. The article alludes to this with the "PBJ sandwich problem" - people are used to specifying processes based on a collective (and often unconscious) cultural understanding, which computers obviously do not share!

[hvidgaard]

I'm inclined to agree. One of the most successful "No Code" programs is Excel. Yet we still, time and time again, see people struggle with basic calculations in it. It's literally elementary school mathematics we're talking about.

I think most "No Code" and especially RPA in general will fall into that. The required mindset to think programmatically is not something the majority of people have unfortunately. But "No Code" will enable those that is somewhat technically inclined and able to think sufficiently programmatically.

[toolslive]

Yes! SQL for example, was invented for business people to allow them to pull their own reports iso having to bother programmers to do it for them. We all know what really happened.

[datavirtue]

Millions of business people pulling their own reports? That is a thing.

[dgb23]

We are doing that though. There are tons of flexible systems like that, where developers provide components/plugins and somewhat technical people, or rather domain experts fit them together for a specific task. Wordpress, Unity3d, Shopify to name a few.