Will low and no code tools ever truly disrupt tech development?

The classic Mythical Man Month makes a crucial distinction between "accidental" and "essential" complexity. Accidental complexity is stuff that it is in your solution, but is not necessary. For example, you added a layer of abstraction that ultimately isn't necessary and doesn't have benefits outweighing the costs. Essential complexity is intrinsic to the problem itself. For example, if you write software to help you file your taxes, you have a certain fundamental amount of complexity that no amount of clever code can get you around, because the problem itself is complicated.

One of the core errors of the most breathless low-/no-code advocacy is that they clearly see that code as it stands today is very complicated, but they think it's all accidental complexity. If we just did the right things... if we just made it easy enough... if we just had the right visual user interface... all this complexity could go away! And then anyone could code! And lo, Utopia would emerge.

There is a grain of truth in this. Code does have accidental and unnecessary complexity. Some traditions and codebases have more, some have less. The low-/no-code approaches can help with this... though I have to qualify it a bit because at times they add their own accidental complexity to problems that traditional approaches don't. But they can be easier sometimes, certainly.

The problem is that even a hypothetically perfect low-/no-code solution with absolutely zero accidental complexity still wouldn't do anything to eliminate the essential complexity of the problems people want solved. I don't care how amazing your no-code UI is. I don't care how visual it is, and how you can grab any 12-year-old off the street and show them your UI and they can grasp everything that's going on. I don't care how much work you put into it. If someone tries to use it to create a tax preparation service, they are going to ram face first into the brick wall of the essential complexity of the problem.

No matter what you do, there are going to be people in the future who have developed a skill set in dealing with that sort of thing, and it isn't going to be a skillset everyone develops to the same degree. Even if you stipulate a domain expert who knows literally everything about the tax code, it will still be a distinct skill to learn how to explain that correctly to a computer, even a zero-accidental-complexity computer.

It is further inevitable that the people dedicated to that will have their own toolset that tunes the expertise and power level to the fact that they are able to pour more time into developing skills that have a longer-term payoff than people who are "programming" for six hours a year.

It is literally impossible for low-/no-code to take over. Even if I pushed a magic button that replaced everything in the world with low-/no-code solutions right now, the world would still bifurcate into the people who further develop their skills with the system, learn how to use it efficiently and effectively, and people who do other things like build houses, provide clean water, etc. The only way to make it so there is no such thing as a "programmer" is to forcibly cap the capability of the universal low-/no-code system so low that there is no way to become better at it, which is just inconceivable.

Totally agree. I've been working on a programming language for UI designers, but it's been years and I doubt I'll ever release it at this point. The idea was to offer a syntax that conforms to their vocabulary and mental models. So if you were designing a button:

  elements
    shape Wrapper
      text Label

  style Wrapper
    fill: blue

  style Label
    content: Click Me
    fill: white

edit: no harm in sharing the demo page that I never released. Warning - it's very broken. But it kinda works: https://matry.design/demo

Exactly. It’s procedural writing at the end of the day: designed by humans, for humans to write.

They are already. I consult for a lot of hyper-early-stage YC startups as they formulate their plans and I've had two separate clients in the past 6 months go the no-code route to build their MVP. At first I was against it, but having seen these clients go through it I would say it is much cheaper and less risky and gives developers an extremely good blueprint for when the founders inevitably decide to go beyond the MVP stage and build their own codebase. No-code platforms are a great way for non-technical (and even technical!) founders to do that hard product work of figuring out what they actually want their app to do and how each screen should work. Things like figma let you do this too, but I find founders will often make something in figma with logic holes or missing flows if they aren't thinking like an engineer. The no-code platforms force you to make these decisions because you'll notice the holes the moment you go to use the app instead of noticing them when your developers go to implement something that doesn't make sense. Much cheaper way to do early iteration.

Depends on the use case.

As someone without a lot of budget to hire devs, I currently use no code in my company extensively, our Airtable has 50 tables, some of them with > 10k records.

There is certain excitement to do all in no-code now, but the ceiling is truly there as the article says, the rule of thumb is that if something is operational and not core for business we do in low code, if it is business critical (we lose money if goes down) then it gets coded.

What happens if our business goes down, and is fault? We can't just say "welp" to our customers complaints, recently we saw that not even Atlassian is immune to long outages.

Also what happens when the market needs for you to do "X" and the tool can't? Now you are stuck in a low-code environment with 3 months migration while the competitors pass ahead. We also got a lot of bugs with this tools on things that were supposed to work, and it slowed us down significantly.

From what I see that the best use case of low code is kickstarting software projects. If done with the right tool (one that allows for easy exporting), it allows to get the data in order for future scaling with code.

Since changing application logic in a living project (and even the entire language / framework) happens all the time, but the data generally does not, this seems like a best case scenario for a new feature or product that still needs to validate their market fit.