4 ms·

My take on it is that no-code misunderstands the problem it’s trying to solve. The root assumption of any tool of this kind is that code is complex. Code isn’t

My take on it is that no-code misunderstands the problem it’s trying to solve. The root assumption of any tool of this kind is that code is complex. Code isn’t complex, it’s simple. Because it’s simple, it’s flexible, and because it’s flexible, it’s often used to solve complex problems. Business people see these complex problems being solved by code and think that the code is what is complex. They don’t understand that the business logic at the heart of the product is what creates the complexity, and that this complexity is still going to be there even if they use a drag-and-drop interface.

rgrieselhuber 4y ago
That’s exactly it.
spikej 4y ago
That's only half the story. Bigger hurdles are the framework fatigue and the constant of having to keep things up to date even after you've got a "complete" product. This is why you see shadow IT in the form of MS Access DBs and spreadsheets that (no matter how terribly implemented) won't die. With no-code, those at least go away. You're no longer having to deal with unnecessary complications of having to learn or deal with WebPack, etc, and you're no longer needing to stay in an endless cycle of dependency hell updates.
- sokoloff 4y ago
  > With no-code, those at least go away. Spreadsheets are no-code that works and has been for decades. No-code won’t kill spreadsheets.
  - kcplate 4y ago
    Half the time the feature requests I get for the product I manage can be summarized to “like…a spreadsheet”. I’m convinced that if the entire business world had its way, it would run entirely within an excel spreadsheet.
    - mathgladiator 4y ago
      I've experienced this too, and it's a reason I'm building a reactive programming language. One way to think about it is a headless spreadsheet. https://www.adama-platform.com/ https://www.adama-platform.com/
      - danielvaughn 4y ago
        I think this is there the real solution lies to this problem. We don't need another drag-and-drop, we need to change how we think about code. I'm building a "programming" language specifically for UI designers. I think high level DSLs are the future.
  - spikej 4y ago
    I wasn't clear... I meant the hurdles go away. Spreadsheets from 90s versions of office still work just fine, whereas my nodejs app from last year is another story
pydry 4y ago
I dont think it's quite so simple. Maybe 70% of business problems fall into a camp that no code tools can deal with and a long tail of 30% that do not. The problem is that: A) No code tools rarely provide good guidance as to where that 70/30 split lies. B) It often takes a good coder to figure out when you've run into this square peg round hole problem and if you use a NCT you probably dont have one to hand and non technical users are SO bad at this (they will often think that they are the problem). C) No code tools often end up reinventing programming languages really badly to bridge that gap instead of bridging like they should in an effort to keep users on their platform and because designing programming languages badly is fun! D) As a result, most people not only misrecognize that 30% long tail and misapply the solution. As a result no code tools have a perpetual allure until they get used on slightly too complex a problem at which point they become uber brittle and everybody starts tearing their hair out. Sometimes the rigidity of the no code tool is baked in, which is even worse (e.g. like this one's bad mobile UX).
- danielvaughn 4y ago
  This is a great response, I agree. One thing I'll add onto point A is that I think it's sometimes impossible to know which side of the 70/30 you're on until the rubber has hit the road and you're deep into implementation. Which of course, complicates the whole thing even further. Take this recent experience of mine - I'm helping someone build a teletech system with Twilio. Nothing too crazy, just connecting customers to a service provider. Seems like the perfect candidate for NCT - heck, even Twilio offers their own in-house NCT (Twilio Studio). I just started building it yesterday and a literal avalanche of questions hit me. What if the call drops? What if the customer isn't happy with the service and wants to speak to someone else? What about (x/y/z) concerns? Before beginning I would have put this project square in the 70%, but now I'm convinced we're in the 30%.

rgrieselhuber 4y ago

That’s exactly it.

spikej 4y ago

That's only half the story. Bigger hurdles are the framework fatigue and the constant of having to keep things up to date even after you've got a "complete" product. This is why you see shadow IT in the form of MS Access DBs and spreadsheets that (no matter how terribly implemented) won't die. With no-code, those at least go away. You're no longer having to deal with unnecessary complications of having to learn or deal with WebPack, etc, and you're no longer needing to stay in an endless cycle of dependency hell updates.

sokoloff 4y ago
> With no-code, those at least go away. Spreadsheets are no-code that works and has been for decades. No-code won’t kill spreadsheets.
- kcplate 4y ago
  Half the time the feature requests I get for the product I manage can be summarized to “like…a spreadsheet”. I’m convinced that if the entire business world had its way, it would run entirely within an excel spreadsheet.
  - mathgladiator 4y ago
    I've experienced this too, and it's a reason I'm building a reactive programming language. One way to think about it is a headless spreadsheet. https://www.adama-platform.com/ https://www.adama-platform.com/
    - danielvaughn 4y ago
      I think this is there the real solution lies to this problem. We don't need another drag-and-drop, we need to change how we think about code. I'm building a "programming" language specifically for UI designers. I think high level DSLs are the future.
- spikej 4y ago
  I wasn't clear... I meant the hurdles go away. Spreadsheets from 90s versions of office still work just fine, whereas my nodejs app from last year is another story

pydry 4y ago

I dont think it's quite so simple. Maybe 70% of business problems fall into a camp that no code tools can deal with and a long tail of 30% that do not. The problem is that: A) No code tools rarely provide good guidance as to where that 70/30 split lies. B) It often takes a good coder to figure out when you've run into this square peg round hole problem and if you use a NCT you probably dont have one to hand and non technical users are SO bad at this (they will often think that they are the problem). C) No code tools often end up reinventing programming languages really badly to bridge that gap instead of bridging like they should in an effort to keep users on their platform and because designing programming languages badly is fun! D) As a result, most people not only misrecognize that 30% long tail and misapply the solution. As a result no code tools have a perpetual allure until they get used on slightly too complex a problem at which point they become uber brittle and everybody starts tearing their hair out. Sometimes the rigidity of the no code tool is baked in, which is even worse (e.g. like this one's bad mobile UX).

danielvaughn 4y ago
This is a great response, I agree. One thing I'll add onto point A is that I think it's sometimes impossible to know which side of the 70/30 you're on until the rubber has hit the road and you're deep into implementation. Which of course, complicates the whole thing even further. Take this recent experience of mine - I'm helping someone build a teletech system with Twilio. Nothing too crazy, just connecting customers to a service provider. Seems like the perfect candidate for NCT - heck, even Twilio offers their own in-house NCT (Twilio Studio). I just started building it yesterday and a literal avalanche of questions hit me. What if the call drops? What if the customer isn't happy with the service and wants to speak to someone else? What about (x/y/z) concerns? Before beginning I would have put this project square in the 70%, but now I'm convinced we're in the 30%.