7 ms·

No code/low code. People here underestimate the work it requires to craft a production CRUD app and keep it working. The problem these tools solve are more rel

No code/low code. People here underestimate the work it requires to craft a production CRUD app and keep it working. The problem these tools solve are more related to infrastructure rather than one's ability to code. Learning to code might be the easiest part but deploying it, maintaining it, scaling it, securing it and integrating it with thousands of other services remains a huge task even for experienced folks. It's wasted time and effort for something that is cookie cutter in functionality and limited in scope (vast majority of web). Some of them provide collaboration tools, development environment and experts on call which is neat. Add ease of outsourcing, too. The employer doesn't have to worry about maintenance once the product is finished. Many good platforms will allow you an easy migration path and better security controls. That comes at a vendor lock in. That's the price but given the life expectancy of smaller companies and startups, it may as well be worth it.

patentatt 6y ago
No-code/low-code is definitely reaching a crescendo of buzz in the legal tech market right now. Which is funny because it’s an idea as old as computers themselves, but there’s a lot of low-hanging fruit still left.
catmanjan 6y ago
No code = someone else's code, it's been around forever, used to be called cots
- dTal 6y ago
  And "cloud" means someone else's computer, been around forever, used to be called mainframes. Didn't stop it from being a marketing explosion.
  - SahAssar 6y ago
    In the "cloud" space I think the difference was being able to sell it as a commodity and in as large or small chunks as the client wanted, not the concept itself. Not sure what the equivalent in no/low-code would be.
    - wtracy 6y ago
      In my mind, "the cloud" came into existence when it became practical to rent servers (virtual or physical) by the hour, rather than by the month. It's one of those things where a difference in degree in implementation terms (leasing in smaller time increments) allowed a difference in kind in usage terms (on-demand server allocation over advance provisioning).
      - SahAssar 6y ago
        Isn't that what I wrote? Or do you disagree with something I wrote?
        xchaotic 6y ago
        I think you are both right but it’s funny because most customers have this stuff up and running 365 days a year anyway
  - deleted 6y ago
    [deleted]
- bitwize 6y ago
  In the 80s it used to be called CASE. It flopped then too.
  - RickJWagner 6y ago
    And 4GLs. About the same time period.
pjmorris 6y ago
> The problem these tools solve are more related to infrastructure rather than one's ability to code. So... SaaS?
jaspax 6y ago
For the past month I've been working on remaking one of our company's internal apps in ReTool. Retool is definitely "lo-code" and not "no-code": you will need to write a few lines of JS, and more than a few lines of SQL, so you do need an actual developer to do the work. However, I was able to replicate about 90% of the functionality of the existing app in a little over a month working by myself, while the full-fledged React app required a team of 3 and had been ongoing for several years. The downside to the user is that certain kinds of UI polish and more complex behaviors aren't possible. From the developer's side, there is limited ability to share code between apps, so you wind up cutting and pasting a lot, and the work is much more boring that regular dev work. Still, it's a lot less work than building up a regular CRUD app.
browsergap 6y ago
I think one of the issues of nolocode is it doesn't actually help people think like programmers, but the tools are often created with the implicit need to do that, a need which the creators don't see because they are coders. People get spreadsheets and word documents. I don't really know why. But they get them. But while it might seem like the step from doc/xls to nolocode is small or even non-existent, I think it actually is really big for most people who are supposed to be the audience for that (complete non developers). I think one reason is because people don't want the responsibility to make a system that can break. I'm not too sure if this is the only or the biggest reason, but I think non-coders don't have the sense that they can build things, and even if you show them they can using some hot tool, it seems they're still scared it's going to break and it will be on them. Maybe one reason is because if you break an Excel doc, there's usually someone around in your org who knows how to fix it. But the same can't be said for some random new hot nocode tool. I think for specific use cases, yes. But for general, web and mobile apps, I just think it is too much complexity you can't simplify away, or at least none of the box-dragging UIs seem to have achieved that. I agree this can be a big market, but a shift is needed to make it actually easy, not "look how easy it is" easy. Taking a different tac, maybe there's just not a market for it. The browser/HTML/JS is everywhere. It's not that hard to build a simple tool or app, but people in orgs use Excel, they don't build a simple page, even. It's not because they couldn't learn how, but somehow that just now what people in orgs do. I don't know why.
- andrewflnr 6y ago
  Part of it is probably that editing a spreadsheet feels much like a direct manipulation of the medium, where programming is much more abstract, made of descriptions.
- d0gbread 6y ago
  The tool I use has three user types: Maker, Editor, and Viewer. Only Makers can make the kinds of changes that would be code. Editors can manipulate the underlying data. Viewers, of course, get read only. The nice thing about this model is that it implies there's a bar to be a Maker and other users can't break your work. You need to be able to reason about concepts like DRY, star schema, cardinality, etc. As a Maker in my org (15-30K people depending on where we are with the pandemic) I can support many no-code apps painlessly in addition to my primary responsibilities, whereas one CRUD app on Heroku had me feeling spread pretty thin.
outime 6y ago
I have been reading the same prediction my whole life so I'm sure this will be a boom at some point by pure chance. But I tend to think that those solutions already exists, and the typical tool coming to mind is WordPress. You literally don't need to know code, just install some plugins that give what you want and go ahead. Pay someone to maintain it (there are tons of companies already). It doesn't need to be WordPress, there are many other platforms. For low code Django comes to mind. For the very typical use cases there are well suited SaaS tools e.g. Shopify for shops. I do think that the very typical cases are well covered. Sure, there's room for improvement but not sure if a real boom is around the corner but as I said I heard this so many times (and also seen so many tries) that well, at some point something may actually happen I guess.
jppope 6y ago
Every VC in the world right now is betting on this becoming a thing... problem is that No Code/ Low Code as a product doesn't actually solve the problem that they are trying to solve. The overarching concept of No Code/ Low Code is that "code" is the hard part of building software, ergo if we can make it so "normal" people don't have to code the problem is solved. Of course we all know that code isn't the hard part of the job- if code was the issue software developers would all be using No Code/ Low Code solutions already (as it's been pointed out, they've been around forever). No Code/ Low Code is about selling accessibility to the wantrepreneur crowd... the same people that have an "app idea" that they want you to build. It's a huge market, but it isn't going to have an impact on software development any more than model rockets would have on the aerospace industry. If the No Code/ Low Code tools were any good software developers would already be using them. (When I am talking about No Code/ Low code, I am not talking about things like Webflow / Dreamweaver NOT solutions like Serverless.)
- bE9a3S5So8igd3 6y ago
  I agree with this. I do wonder if low/no-code products will ever become good enough that you'd feel comfortable actually using one. I believe a part of this is having infrastructure/system that can describe itself in sufficient detail. Then the ability to modify itself with sufficient variety. Fundamentally I've seen ORMs/APIs/integrations that are more or less a crap shoot as to whether or not they're going to work, god forbid if a version of something is upgraded. The fallibility of it all will prevent this from happening.
  - jppope 6y ago
    they totally will... but it's probably going to show up the way you would expect it to... some open source project will get really good at helping you configure 95% of your app with a CLI or something... then you'll mod some methods etc. Eventually that will transform into something that can predict what you'll need. IMO stuff like serverless, OpenAPI, some of the boilerplates out there, etc are already heading in that direction. It used to take me a week to build a standard CRUD API with a handful of models, now I can do it circa 15-30min.
- 6y ago
ww520 6y ago
As an example, the best and most successful no-code low-code product was and is Excel.
- bE9a3S5So8igd3 6y ago
  Excel is spreadsheet application. It is not related to the parent post, which discusses networked CRUD application, with various integration points, DB, caching, redundant deployments, etc..
  - deleted 6y ago
    [deleted]
  - Matthias247 6y ago
    I've experienced Excel being used with all of those in bigger non-tech companies. Integration points: Everyone sends their version to Person A, and they integrate it, filter it, postprocess it, extracts parts into another sheet, etc. Caching: Everyone has their own version of the excel sheet in their local inbox. Redundant: There's typically plenty of shared directories on which you can find the same excel sheet in different versions.
    - bE9a3S5So8igd3 6y ago
      lol, HN melodrama-purists downvoting No, Excel is not relevant to the conversation. Excel is a standalone desktop application. No, Excel is not an example of a "no-code" webapp. Do you seriously need another adult to tell you these things?
codegeek 6y ago
Kinda like MS Access ? I am only half joking :)
tyingq 6y ago
I like, and use these tools. Getting it right is hard though. Google just shuttered their AppMaker, which I thought was one of the better attempts.
lubujackson 6y ago
I think the real shift will be in "no code experts" who get paid more than actual programmers because they learn how to deal with the limitations and extend them for businesses who already have sunk costs in them. A perfect example is Excel experts who can do very well because Excel has symbiotically intertwined with how many businesses operate. Or COBOL experts who get paid because nobody learns COBOL but places refused to upgrade. Servicing software debt is an industry in itself.
- miek 6y ago
  I am predicting this at the large firm where i work. They use terms like "robotics" and "ai robots". The primary line of thought being touted across the firm is "easier to transfer and maintain than traditional code", but there is substantial gatekeeping occurring. I assume license prices are high, because there are not many per department. I am guessing that some of the "automators" holding these scarce licenses will develop a nice moat for themselves if they can prove their value. I sat in on a meeting where the "automator" and his manager said they were seeking to automate high-time-savings/high-risk tasks first (risk being large potential dollar loss, legal exposure, etc. upon failure), which is odd but great for visibility and moat-building (given that fear of traditional code brought them to this point, fear of being unable to properly maintain the ""robots"" could easily come next)
- muzani 6y ago
  I feel like this will be like WordPress at best, and Cordova at worst. WP lets someone with no formal CS training do wonders, and I think it's a good thing. Cordova tries to save time and cost, but you need people with above average skill to hack things, know all the gotchas and bugs of the no-code system, all the undocumented bits, but still deal with the risks. Nobody wants to do the plumbing, nobody wants to dedicate their career to it, and so it ends up overpriced to the buyer and underpriced to the seller. You could also end up with something like Parse, which had some of the best handovers from closed into open source, but the stigma of being dropped by a major tech company made people avoid it.
tmaly 6y ago
I think low code/no code could really change thing if they can figure out how to make declarative code fast. Think Prolog etc
- ptttr 6y ago
  You're on to something. Low code platforms, at their core, allow you to define the software with data (from predefined components usually through UI) and that's how they enable super productivity, until you hit a wall. Data Declarative programming paradigm could potentially achieve the same levels of productivity without its limitations but it's very difficult to get the right implementation. The most interesting development in this area I had found, is Fulcro Rapid Application Development Tools [1] - a fullstack clojure framework that's performant, declarative and extensible. RAD is still alpha but it bases on battle-proved Fulcro. Once you hit the limits of declarative RAD you can easily extend it with regular Fulcro components which are, in their essence, a cheap abstraction over React/React Native components - offering industry standard performance. [1] https://github.com/fulcrologic/fulcro-rad https://github.com/fulcrologic/fulcro-rad
mattmanser 6y ago
They tried this in the 90s and 00s. It was such a spectacular failure it's funny to see it recycled. And for you to claim you wouldn't have to worry about maintenance is especially comical. It was extremely high maintenance and expensive, and it often broke. Programmers don't just code a problem, they solve the problem. Teasing out the actual business logic is as much a part of the job as anything else, and one that most employees and managers are so clueless and utterly useless at that any no code solution will require a programmer to actually use it any way. But without any of the flexibility code gives, you end up with tons of dumb, manual, expensive, hacks and a sub-standard product. Eventually the 'no-code' platform adds the ability to use some code and you end up with a really shitty software platform that delivers 80%, but the effort required to get that last 20% is far in excess of just starting again and writing it from scratch in code. Ask any programmer who remembers workflow software their experience and you will learn from the mistakes of two decades ago.
- tdeck 6y ago
  Tried it in the '80s too, here's an ad from around 1981 https://thedailywtf.com/images/ads/All-programs-you-need-small.png https://thedailywtf.com/images/ads/All-programs-you-need-sma... https://en.wikipedia.org/wiki/The_Last_One_%28software%29 https://en.wikipedia.org/wiki/The_Last_One_%28software%29
- giantg2 6y ago
  "Teasing out the actual business logic is as much a part of the job as anything else..." That's the definition of a programmer analyst or business analyst. If the business is too cheap or clueless to create business process maps or hire someone as a process efficiency expert, then they are certainly too cheap fund properly developed software and too clueless to intelligently answer the questions that an IT resource has to use to tease out an answer. I do agree that no-code is not going to replace the need for software professionals.
bitwize 6y ago
No code/low code is snake oil that gets sold to us every few years, and always fails to take hold. The reason why is because by the time you get the GUI widgets, hand gestures, whistled tones, or whatever in your low-code solution specific enough to be interpretable by computer, what you've come up with is isomorphic to constructs in some programming language. (And don't say "But AI will solve this problem!": anything intelligent enough to turn vague requirements into working programs outside very well specified constraints is intelligent enough to demand compensation negotiations for continued output.) So you really haven't made the code go away; you've disguised it as something that isn't code. This actually works well for tricking people into programming when they otherwise wouldn't. And this itself is a viable strategy: consider the secretaries in the 1970s who used Lisp to "customize" Multics Emacs and were never told they were programming it. But it doesn't eliminate the complexity of coding. And most "no-code/low-code" platforms have disadvantages (vendor lock, extremely limited applicability, zero portability) that are almost guaranteed to bite you in the ass later.
- deleted 6y ago
  [deleted]
jiggawatts 6y ago
What a lot of people replying to this are missing is that nobody wants visual drag & drop systems. Not coders, not "no-coders". Not anybody. This is the root cause of an endless series of failed ventures and products. The successful no-code products are something else entirely, merely masquerading as no-code. Excel is probably the prototypical example of this: it is a reactive dataflow system, but you'll never find any dragable widgets with little input ports and output ports you can connect. It's trivial to get started with Excel. It's trivial to connect cells and get some computations going. It's then a nice smooth transition all the way up to multidimensional analysis, and not once do you have to break out into a full programming language. That's what people want. What you imagine they want is something childish and useless. To be honest, it's simply arrogance. By assuming the user can't code, it's natural to assume that they think at a level of a young child and need only toys. For fuck's sake, Excel is 64-bit and fully parallel! Did you know that? I've seen 60 year old ladies from accounting produce spreadsheets that can bring a 16-core terminal server to its knees, and that spreadsheet was doing entirely legitimate, useful, productive computation. Show me the last system you built that can efficiently utilise a modern high-core CPU for a single user! Your market is adults. They need power tools, not toys. Start thinking like that, and you'll have a successful product.
juancn 6y ago
I’ve been part of a couple no code/low code platforms. They pop up every decade and do ok for a while and then wither and die, only to be replaced by the next gen of them. 4GL (fourth gen languages), BPM systems, things like clipper or dbase, access, even VB is a low code kind of platform. The new generation focuses on web tech and mobile, and they’ll do well for a while, until the landscape changes enough and they accumulate enough cruft to become unwieldy to use. In 10 years or so we’ll be talking about something like that again.

patentatt 6y ago

No-code/low-code is definitely reaching a crescendo of buzz in the legal tech market right now. Which is funny because it’s an idea as old as computers themselves, but there’s a lot of low-hanging fruit still left.

catmanjan 6y ago

No code = someone else's code, it's been around forever, used to be called cots

dTal 6y ago
And "cloud" means someone else's computer, been around forever, used to be called mainframes. Didn't stop it from being a marketing explosion.
- SahAssar 6y ago
  In the "cloud" space I think the difference was being able to sell it as a commodity and in as large or small chunks as the client wanted, not the concept itself. Not sure what the equivalent in no/low-code would be.
  - wtracy 6y ago
    In my mind, "the cloud" came into existence when it became practical to rent servers (virtual or physical) by the hour, rather than by the month. It's one of those things where a difference in degree in implementation terms (leasing in smaller time increments) allowed a difference in kind in usage terms (on-demand server allocation over advance provisioning).
    - SahAssar 6y ago
      Isn't that what I wrote? Or do you disagree with something I wrote?
      - xchaotic 6y ago
        I think you are both right but it’s funny because most customers have this stuff up and running 365 days a year anyway
- deleted 6y ago
  [deleted]
bitwize 6y ago
In the 80s it used to be called CASE. It flopped then too.
- RickJWagner 6y ago
  And 4GLs. About the same time period.

pjmorris 6y ago

> The problem these tools solve are more related to infrastructure rather than one's ability to code. So... SaaS?

jaspax 6y ago

For the past month I've been working on remaking one of our company's internal apps in ReTool. Retool is definitely "lo-code" and not "no-code": you will need to write a few lines of JS, and more than a few lines of SQL, so you do need an actual developer to do the work. However, I was able to replicate about 90% of the functionality of the existing app in a little over a month working by myself, while the full-fledged React app required a team of 3 and had been ongoing for several years. The downside to the user is that certain kinds of UI polish and more complex behaviors aren't possible. From the developer's side, there is limited ability to share code between apps, so you wind up cutting and pasting a lot, and the work is much more boring that regular dev work. Still, it's a lot less work than building up a regular CRUD app.

browsergap 6y ago

I think one of the issues of nolocode is it doesn't actually help people think like programmers, but the tools are often created with the implicit need to do that, a need which the creators don't see because they are coders. People get spreadsheets and word documents. I don't really know why. But they get them. But while it might seem like the step from doc/xls to nolocode is small or even non-existent, I think it actually is really big for most people who are supposed to be the audience for that (complete non developers). I think one reason is because people don't want the responsibility to make a system that can break. I'm not too sure if this is the only or the biggest reason, but I think non-coders don't have the sense that they can build things, and even if you show them they can using some hot tool, it seems they're still scared it's going to break and it will be on them. Maybe one reason is because if you break an Excel doc, there's usually someone around in your org who knows how to fix it. But the same can't be said for some random new hot nocode tool. I think for specific use cases, yes. But for general, web and mobile apps, I just think it is too much complexity you can't simplify away, or at least none of the box-dragging UIs seem to have achieved that. I agree this can be a big market, but a shift is needed to make it actually easy, not "look how easy it is" easy. Taking a different tac, maybe there's just not a market for it. The browser/HTML/JS is everywhere. It's not that hard to build a simple tool or app, but people in orgs use Excel, they don't build a simple page, even. It's not because they couldn't learn how, but somehow that just now what people in orgs do. I don't know why.

andrewflnr 6y ago
Part of it is probably that editing a spreadsheet feels much like a direct manipulation of the medium, where programming is much more abstract, made of descriptions.
d0gbread 6y ago
The tool I use has three user types: Maker, Editor, and Viewer. Only Makers can make the kinds of changes that would be code. Editors can manipulate the underlying data. Viewers, of course, get read only. The nice thing about this model is that it implies there's a bar to be a Maker and other users can't break your work. You need to be able to reason about concepts like DRY, star schema, cardinality, etc. As a Maker in my org (15-30K people depending on where we are with the pandemic) I can support many no-code apps painlessly in addition to my primary responsibilities, whereas one CRUD app on Heroku had me feeling spread pretty thin.

outime 6y ago

I have been reading the same prediction my whole life so I'm sure this will be a boom at some point by pure chance. But I tend to think that those solutions already exists, and the typical tool coming to mind is WordPress. You literally don't need to know code, just install some plugins that give what you want and go ahead. Pay someone to maintain it (there are tons of companies already). It doesn't need to be WordPress, there are many other platforms. For low code Django comes to mind. For the very typical use cases there are well suited SaaS tools e.g. Shopify for shops. I do think that the very typical cases are well covered. Sure, there's room for improvement but not sure if a real boom is around the corner but as I said I heard this so many times (and also seen so many tries) that well, at some point something may actually happen I guess.

jppope 6y ago

Every VC in the world right now is betting on this becoming a thing... problem is that No Code/ Low Code as a product doesn't actually solve the problem that they are trying to solve. The overarching concept of No Code/ Low Code is that "code" is the hard part of building software, ergo if we can make it so "normal" people don't have to code the problem is solved. Of course we all know that code isn't the hard part of the job- if code was the issue software developers would all be using No Code/ Low Code solutions already (as it's been pointed out, they've been around forever). No Code/ Low Code is about selling accessibility to the wantrepreneur crowd... the same people that have an "app idea" that they want you to build. It's a huge market, but it isn't going to have an impact on software development any more than model rockets would have on the aerospace industry. If the No Code/ Low Code tools were any good software developers would already be using them. (When I am talking about No Code/ Low code, I am not talking about things like Webflow / Dreamweaver NOT solutions like Serverless.)

bE9a3S5So8igd3 6y ago
I agree with this. I do wonder if low/no-code products will ever become good enough that you'd feel comfortable actually using one. I believe a part of this is having infrastructure/system that can describe itself in sufficient detail. Then the ability to modify itself with sufficient variety. Fundamentally I've seen ORMs/APIs/integrations that are more or less a crap shoot as to whether or not they're going to work, god forbid if a version of something is upgraded. The fallibility of it all will prevent this from happening.
- jppope 6y ago
  they totally will... but it's probably going to show up the way you would expect it to... some open source project will get really good at helping you configure 95% of your app with a CLI or something... then you'll mod some methods etc. Eventually that will transform into something that can predict what you'll need. IMO stuff like serverless, OpenAPI, some of the boilerplates out there, etc are already heading in that direction. It used to take me a week to build a standard CRUD API with a handful of models, now I can do it circa 15-30min.
6y ago

ww520 6y ago

As an example, the best and most successful no-code low-code product was and is Excel.

bE9a3S5So8igd3 6y ago
Excel is spreadsheet application. It is not related to the parent post, which discusses networked CRUD application, with various integration points, DB, caching, redundant deployments, etc..
- deleted 6y ago
  [deleted]
- Matthias247 6y ago
  I've experienced Excel being used with all of those in bigger non-tech companies. Integration points: Everyone sends their version to Person A, and they integrate it, filter it, postprocess it, extracts parts into another sheet, etc. Caching: Everyone has their own version of the excel sheet in their local inbox. Redundant: There's typically plenty of shared directories on which you can find the same excel sheet in different versions.
  - bE9a3S5So8igd3 6y ago
    lol, HN melodrama-purists downvoting No, Excel is not relevant to the conversation. Excel is a standalone desktop application. No, Excel is not an example of a "no-code" webapp. Do you seriously need another adult to tell you these things?

codegeek 6y ago

Kinda like MS Access ? I am only half joking :)

tyingq 6y ago

I like, and use these tools. Getting it right is hard though. Google just shuttered their AppMaker, which I thought was one of the better attempts.

lubujackson 6y ago

I think the real shift will be in "no code experts" who get paid more than actual programmers because they learn how to deal with the limitations and extend them for businesses who already have sunk costs in them. A perfect example is Excel experts who can do very well because Excel has symbiotically intertwined with how many businesses operate. Or COBOL experts who get paid because nobody learns COBOL but places refused to upgrade. Servicing software debt is an industry in itself.

miek 6y ago
I am predicting this at the large firm where i work. They use terms like "robotics" and "ai robots". The primary line of thought being touted across the firm is "easier to transfer and maintain than traditional code", but there is substantial gatekeeping occurring. I assume license prices are high, because there are not many per department. I am guessing that some of the "automators" holding these scarce licenses will develop a nice moat for themselves if they can prove their value. I sat in on a meeting where the "automator" and his manager said they were seeking to automate high-time-savings/high-risk tasks first (risk being large potential dollar loss, legal exposure, etc. upon failure), which is odd but great for visibility and moat-building (given that fear of traditional code brought them to this point, fear of being unable to properly maintain the ""robots"" could easily come next)
muzani 6y ago
I feel like this will be like WordPress at best, and Cordova at worst. WP lets someone with no formal CS training do wonders, and I think it's a good thing. Cordova tries to save time and cost, but you need people with above average skill to hack things, know all the gotchas and bugs of the no-code system, all the undocumented bits, but still deal with the risks. Nobody wants to do the plumbing, nobody wants to dedicate their career to it, and so it ends up overpriced to the buyer and underpriced to the seller. You could also end up with something like Parse, which had some of the best handovers from closed into open source, but the stigma of being dropped by a major tech company made people avoid it.

tmaly 6y ago

I think low code/no code could really change thing if they can figure out how to make declarative code fast. Think Prolog etc

ptttr 6y ago
You're on to something. Low code platforms, at their core, allow you to define the software with data (from predefined components usually through UI) and that's how they enable super productivity, until you hit a wall. Data Declarative programming paradigm could potentially achieve the same levels of productivity without its limitations but it's very difficult to get the right implementation. The most interesting development in this area I had found, is Fulcro Rapid Application Development Tools [1] - a fullstack clojure framework that's performant, declarative and extensible. RAD is still alpha but it bases on battle-proved Fulcro. Once you hit the limits of declarative RAD you can easily extend it with regular Fulcro components which are, in their essence, a cheap abstraction over React/React Native components - offering industry standard performance. [1] https://github.com/fulcrologic/fulcro-rad https://github.com/fulcrologic/fulcro-rad

mattmanser 6y ago

They tried this in the 90s and 00s. It was such a spectacular failure it's funny to see it recycled. And for you to claim you wouldn't have to worry about maintenance is especially comical. It was extremely high maintenance and expensive, and it often broke. Programmers don't just code a problem, they solve the problem. Teasing out the actual business logic is as much a part of the job as anything else, and one that most employees and managers are so clueless and utterly useless at that any no code solution will require a programmer to actually use it any way. But without any of the flexibility code gives, you end up with tons of dumb, manual, expensive, hacks and a sub-standard product. Eventually the 'no-code' platform adds the ability to use some code and you end up with a really shitty software platform that delivers 80%, but the effort required to get that last 20% is far in excess of just starting again and writing it from scratch in code. Ask any programmer who remembers workflow software their experience and you will learn from the mistakes of two decades ago.

tdeck 6y ago
Tried it in the '80s too, here's an ad from around 1981 https://thedailywtf.com/images/ads/All-programs-you-need-small.png https://thedailywtf.com/images/ads/All-programs-you-need-sma... https://en.wikipedia.org/wiki/The_Last_One_%28software%29 https://en.wikipedia.org/wiki/The_Last_One_%28software%29
giantg2 6y ago
"Teasing out the actual business logic is as much a part of the job as anything else..." That's the definition of a programmer analyst or business analyst. If the business is too cheap or clueless to create business process maps or hire someone as a process efficiency expert, then they are certainly too cheap fund properly developed software and too clueless to intelligently answer the questions that an IT resource has to use to tease out an answer. I do agree that no-code is not going to replace the need for software professionals.

bitwize 6y ago

No code/low code is snake oil that gets sold to us every few years, and always fails to take hold. The reason why is because by the time you get the GUI widgets, hand gestures, whistled tones, or whatever in your low-code solution specific enough to be interpretable by computer, what you've come up with is isomorphic to constructs in some programming language. (And don't say "But AI will solve this problem!": anything intelligent enough to turn vague requirements into working programs outside very well specified constraints is intelligent enough to demand compensation negotiations for continued output.) So you really haven't made the code go away; you've disguised it as something that isn't code. This actually works well for tricking people into programming when they otherwise wouldn't. And this itself is a viable strategy: consider the secretaries in the 1970s who used Lisp to "customize" Multics Emacs and were never told they were programming it. But it doesn't eliminate the complexity of coding. And most "no-code/low-code" platforms have disadvantages (vendor lock, extremely limited applicability, zero portability) that are almost guaranteed to bite you in the ass later.

deleted 6y ago
[deleted]

jiggawatts 6y ago

What a lot of people replying to this are missing is that nobody wants visual drag & drop systems. Not coders, not "no-coders". Not anybody. This is the root cause of an endless series of failed ventures and products. The successful no-code products are something else entirely, merely masquerading as no-code. Excel is probably the prototypical example of this: it is a reactive dataflow system, but you'll never find any dragable widgets with little input ports and output ports you can connect. It's trivial to get started with Excel. It's trivial to connect cells and get some computations going. It's then a nice smooth transition all the way up to multidimensional analysis, and not once do you have to break out into a full programming language. That's what people want. What you imagine they want is something childish and useless. To be honest, it's simply arrogance. By assuming the user can't code, it's natural to assume that they think at a level of a young child and need only toys. For fuck's sake, Excel is 64-bit and fully parallel! Did you know that? I've seen 60 year old ladies from accounting produce spreadsheets that can bring a 16-core terminal server to its knees, and that spreadsheet was doing entirely legitimate, useful, productive computation. Show me the last system you built that can efficiently utilise a modern high-core CPU for a single user! Your market is adults. They need power tools, not toys. Start thinking like that, and you'll have a successful product.

juancn 6y ago

I’ve been part of a couple no code/low code platforms. They pop up every decade and do ok for a while and then wither and die, only to be replaced by the next gen of them. 4GL (fourth gen languages), BPM systems, things like clipper or dbase, access, even VB is a low code kind of platform. The new generation focuses on web tech and mobile, and they’ll do well for a while, until the landscape changes enough and they accumulate enough cruft to become unwieldy to use. In 10 years or so we’ll be talking about something like that again.