6 ms·

Things we agree on: ignore everything no-code proponents say about their tools or capabilities Things we disagree on: code before no code My experience has be

by ethbr0 5y ago

Things we agree on: ignore everything no-code proponents say about their tools or capabilities Things we disagree on: code before no code My experience has been that actual code is always superior* to no-code, because no-code is always more complex. E.g. the no-code developer environment + code (in whatever designer form) + interpreter / runtime / libraries + any integrations + actual generated code. Consequently, business critical functions should be in actual code, if it's an option. So where and why to use no-code? As a prototyping tool, no-code before code, because it inverts the pyramid (few developers, many users) by making users into prototyping developers, and it makes the best use of scarce resources (code developer time). No-code written by users allows you to waste user time figuring out all the things that are typically missing in a business spec, without wasting developer time. Then, when they've figured out exactly what they want (because it works!), developers can come back and do exactly that. This usually involves throwing away the no-code model when coding, because it's probably not going to be architected well, but does provide a concrete, tested, proven spec. So essentially, the company gets version 2 of the code, at the cost of 1x user time + 1x developer time. Instead of version 2 of the code, in 2x developer time, which is too expensive and never happens. * From a TCO, maintenance and reliability standpoint

johncowan 5y ago
SQL is no/low-code compared to using a low-level database like BDB for a given level of power. And yet it's much simpler for most use cases. By the same token, C is low-code compared to assembler, Python is low-code compared to C, and Steel Bank Common Lisp is low-code compared to Python.
- makerdiety 5y ago
  Using the same kind of reasoning, JavaScript is a framework and JQuery is no code. Or maybe React and Angular are no code and JQuery is low code? We basically need a firm, objective basis for determining what a thing is. The question is: what is it?
mdpye 5y ago
I suspect you are talking at cross purposes. You are suggesting no-code first on a micro timescale. For prototyping. That seems like a solid suggestion and use of resources. But from the GP, I read a statement on the macro scale. No-code can't codify turn-key pluggable building blocks until the problem spaces of those blocks have been thoroughly explored by code solutions, and a small number of "winning" configurations identified. Sure, those blocks can be plugged together to prototype "novel" line of business "problems", but I think there's a disconnect in the kind of problem spaces you are talking about. The "solved" problems that the no-code widgets represent still need to be solved by code first. And expectations continue to move.
- ethbr0 5y ago
  We have a different definition of no-code, I think. I wasn't including any tools that don't offer generic enough primitives to build an arbitrary business process. If we're reducing no-code to "things that have been written in code first, that can then be plugged together by the no-code user", then we're talking about libraries with a visual designer on top.
  - eropple 5y ago
    I think you’re thinking higher level than the other side of this conversation thread? Maybe a better way to describe it is that you couldn’t build something like Retool (which is super cool, I like it) without a lot of prior formative design around CRUD and repeatable consistent model handling even across very different data stores and dealing with double-sent commits and the like. No-code approaches need to be prescriptive about how they deal with systems and it takes a long time to get to the point where we know how to do that in a way that won’t infuriate people.
    - ethbr0 5y ago
      I guess here is where "no-code" as a big-tent term breaks down. Most of the targeted products in the space seem like they can be expressed as "I know how to ___, but I don't want to ___" (f.ex. Retool looks like: write a query, write a UI). Which, yes, trade opinionated design for design time efficiency, which is most of their value. On the other hand, you also have no-code frameworks which are icons and a designer wrapped around primitives that afford you enough access to control flow and variables to build anything you could code. E.g. Node-RED, UiPath, or Power Automate. Which don't need to be very opinionated, because their entire purpose is to be a build-anything toolbox. So it's probably more useful to differentiate focused no-code products from general-purpose ones.
rizz0 5y ago
>So essentially, the company gets version 2 of the code, at the cost of 1x user time + 1x developer time. Instead of version 2 of the code, in 2x developer time, which is too expensive and never happens. Not sure why, but in my experience the difference has been closer to 1x user time + 1x developer time <> 4x developer time. I believe empowering a customer to think along — be pushed to their limits, even — within the boundaries of a system's technical/business domain _from the very start_ is likely to dramatically improve a system's design. From a technical perspective it may not be architected well, but in terms of user <> business fit it probably will be.
wonderwonder 5y ago
I used to think this as well, that No Code was not a real development to production level option. I have very much been proven wrong. I transition recently from 15+ years as a developer to contracting for a no code platform. Virtually everything a regular web dev can do in code can be done in no code. Sometimes its easier to do in code and sometimes it is much easier to do in no code so mileage may vary but no code is very much a mature technology now that can produce applications to the same scale as regular web 2.0 coded software.
- ethbr0 5y ago
  I've been consulting in no-code platforms, in addition to writing actual code, for about 8 years. Producing something that works isn't the problem. Maintaining it is. The legacy codebases from this stuff are dumpster fires, because most of the tools are closed enough ecosystems that the companies supporting them have to reinvent every programming best practice from the last 30 years. 'Version control? Sure, that's a feature on our roadmap that we'll get to at some point...' In addition to going back to the bad old days of limited-use, proprietary compiler problems. 'Oh, that bug? Yeah, just don't do that.' Furthermore, unless you choose very carefully, you're playing right into vendor lock-in, and a lot of the people buying this stuff aren't technically proficient enough to realize that. Once these companies hit the end of the easy growth ramp, and the industry turns into monetizing & squeezing existing customers, there's going to be migration pain on an Oracle scale.
  - winterplace 5y ago
    Maintainability is always the issue, even for the things made from code. What do you think will happen if the no-code platforms become open source?
    - ethbr0 5y ago
      Every general no code platform I've worked with has had an order of magnitude (sometimes, multiple) worse maintainability story than code alternatives. And admittedly, maybe I've worked with a series of terrible ones, but I've also worked with a lot of popular ones that big enterprises are adopting. As for open source, I'd say zero percent chance that happens, because no code solves problems developers don't have: (1) I want to write code, but I don't know how to code & (2) I need to integrate a lot of really boring, legacy, usually-Windows apps. It's the "Why are there no polished open source desktop environments?" problem from the 90s, multiplied by ten. Which I think is why you see what open source no-code tools do exist focus on web, because that's closer to what their developers are curious about.
sam0x17 5y ago
> My experience has been that actual code is always superior* to no-code, because no-code is always more complex Yes, usually an order of magnitude more complex, even.
hyperpallium2 5y ago
I like this idea, but does it work in praxtice?
deleted 5y ago
[deleted]
hermitcrab 5y ago
Maintenance is a big issue when you are using a no-code system to create another system which someone else will use (e.g. to create a business application). But if you are using a no-code system to create an artefact (e.g. to wrangle data into a new format) then that issue isn't so relevant.

by ethbr0 5y ago

johncowan 5y ago

SQL is no/low-code compared to using a low-level database like BDB for a given level of power. And yet it's much simpler for most use cases. By the same token, C is low-code compared to assembler, Python is low-code compared to C, and Steel Bank Common Lisp is low-code compared to Python.

makerdiety 5y ago
Using the same kind of reasoning, JavaScript is a framework and JQuery is no code. Or maybe React and Angular are no code and JQuery is low code? We basically need a firm, objective basis for determining what a thing is. The question is: what is it?

mdpye 5y ago

I suspect you are talking at cross purposes. You are suggesting no-code first on a micro timescale. For prototyping. That seems like a solid suggestion and use of resources. But from the GP, I read a statement on the macro scale. No-code can't codify turn-key pluggable building blocks until the problem spaces of those blocks have been thoroughly explored by code solutions, and a small number of "winning" configurations identified. Sure, those blocks can be plugged together to prototype "novel" line of business "problems", but I think there's a disconnect in the kind of problem spaces you are talking about. The "solved" problems that the no-code widgets represent still need to be solved by code first. And expectations continue to move.

ethbr0 5y ago
We have a different definition of no-code, I think. I wasn't including any tools that don't offer generic enough primitives to build an arbitrary business process. If we're reducing no-code to "things that have been written in code first, that can then be plugged together by the no-code user", then we're talking about libraries with a visual designer on top.
- eropple 5y ago
  I think you’re thinking higher level than the other side of this conversation thread? Maybe a better way to describe it is that you couldn’t build something like Retool (which is super cool, I like it) without a lot of prior formative design around CRUD and repeatable consistent model handling even across very different data stores and dealing with double-sent commits and the like. No-code approaches need to be prescriptive about how they deal with systems and it takes a long time to get to the point where we know how to do that in a way that won’t infuriate people.
  - ethbr0 5y ago
    I guess here is where "no-code" as a big-tent term breaks down. Most of the targeted products in the space seem like they can be expressed as "I know how to ___, but I don't want to ___" (f.ex. Retool looks like: write a query, write a UI). Which, yes, trade opinionated design for design time efficiency, which is most of their value. On the other hand, you also have no-code frameworks which are icons and a designer wrapped around primitives that afford you enough access to control flow and variables to build anything you could code. E.g. Node-RED, UiPath, or Power Automate. Which don't need to be very opinionated, because their entire purpose is to be a build-anything toolbox. So it's probably more useful to differentiate focused no-code products from general-purpose ones.

rizz0 5y ago

>So essentially, the company gets version 2 of the code, at the cost of 1x user time + 1x developer time. Instead of version 2 of the code, in 2x developer time, which is too expensive and never happens. Not sure why, but in my experience the difference has been closer to 1x user time + 1x developer time <> 4x developer time. I believe empowering a customer to think along — be pushed to their limits, even — within the boundaries of a system's technical/business domain _from the very start_ is likely to dramatically improve a system's design. From a technical perspective it may not be architected well, but in terms of user <> business fit it probably will be.

wonderwonder 5y ago

I used to think this as well, that No Code was not a real development to production level option. I have very much been proven wrong. I transition recently from 15+ years as a developer to contracting for a no code platform. Virtually everything a regular web dev can do in code can be done in no code. Sometimes its easier to do in code and sometimes it is much easier to do in no code so mileage may vary but no code is very much a mature technology now that can produce applications to the same scale as regular web 2.0 coded software.

ethbr0 5y ago
I've been consulting in no-code platforms, in addition to writing actual code, for about 8 years. Producing something that works isn't the problem. Maintaining it is. The legacy codebases from this stuff are dumpster fires, because most of the tools are closed enough ecosystems that the companies supporting them have to reinvent every programming best practice from the last 30 years. 'Version control? Sure, that's a feature on our roadmap that we'll get to at some point...' In addition to going back to the bad old days of limited-use, proprietary compiler problems. 'Oh, that bug? Yeah, just don't do that.' Furthermore, unless you choose very carefully, you're playing right into vendor lock-in, and a lot of the people buying this stuff aren't technically proficient enough to realize that. Once these companies hit the end of the easy growth ramp, and the industry turns into monetizing & squeezing existing customers, there's going to be migration pain on an Oracle scale.
- winterplace 5y ago
  Maintainability is always the issue, even for the things made from code. What do you think will happen if the no-code platforms become open source?
  - ethbr0 5y ago
    Every general no code platform I've worked with has had an order of magnitude (sometimes, multiple) worse maintainability story than code alternatives. And admittedly, maybe I've worked with a series of terrible ones, but I've also worked with a lot of popular ones that big enterprises are adopting. As for open source, I'd say zero percent chance that happens, because no code solves problems developers don't have: (1) I want to write code, but I don't know how to code & (2) I need to integrate a lot of really boring, legacy, usually-Windows apps. It's the "Why are there no polished open source desktop environments?" problem from the 90s, multiplied by ten. Which I think is why you see what open source no-code tools do exist focus on web, because that's closer to what their developers are curious about.

sam0x17 5y ago

> My experience has been that actual code is always superior* to no-code, because no-code is always more complex Yes, usually an order of magnitude more complex, even.

hyperpallium2 5y ago

I like this idea, but does it work in praxtice?

deleted 5y ago

[deleted]

hermitcrab 5y ago

Maintenance is a big issue when you are using a no-code system to create another system which someone else will use (e.g. to create a business application). But if you are using a no-code system to create an artefact (e.g. to wrangle data into a new format) then that issue isn't so relevant.