5 ms·

The heart of this complaint is essentially that some people think that the difficulty in implementing something is because it requires code, and they can’t writ

The heart of this complaint is essentially that some people think that the difficulty in implementing something is because it requires code, and they can’t write code. “If only I could code, this would be easy”, they think. Code, as they view it, is incidental complexity, not essential complexity. For a lot of tasks, this is actually true. Take away the requirement to write code by supplying them with a low code tool, and suddenly people can do lots of useful things that they couldn’t before. So in that respect, it’s no lie. But of course, there are a tonne of other situations, where code is not the only complexity present. Sometimes you’re just trying to solve a big, complex problem. Take away the coding requirement, and you’re still left with a tonne of complexity to manage. And low-code tools aren’t the best for handling that. In those cases, you’re better off hiring developers. I’ve seen a few people build very complex things using low code tools. Modern ones, but also going all the way back to the original low code tool itself, spreadsheets. People really can build huge things with them. But after a certain degree of size and complexity, it’s more trouble than it’s worth to go with low code tools. But that doesn’t mean low code tools are useless – they are great for the first set of problems, where the code required is just incidental complexity. You shouldn’t write off this substantially useful product category just because people get into trouble using them for problems they aren’t suitable for.

Closi 4y ago
Totally agree - right tool right job. Sometimes writing a full web application is the right solution, other times you just need a database with a front end and a low-code solution is best, other times an excel spreadsheet will be the right solution, and other times just physical process change is best. Why take something out of your toolbox?
- pydry 4y ago
  >other times you just need a database with a front end and a low-code solution is best Until you need it to do something slightly beyond its capabilities and then you are trapped with an app that needs to be rewritten with data that needs to be migrated in order to implement one small feature.
  - Closi 4y ago
    That's the same thing with all technology choices though - if requirements change substantially you always risk a rewrite. If write a full-code application with all your logic in server-side .NET and suddenly your users have a requirement to use it offline, and then you are trapped with an app that needs to be rewritten with data that needs to be migrated in order to implement one feature This is all part of having a good level of intuition for what capabilities you are likely to need, and then picking appropriate technology.
    - pydry 4y ago
      There is a vast difference between the things which are blocked because youre not using a turing complete programming language and things which are blocked because of the nature of that language though. You'll probably run up against the former quite quickly. The latter possibly never.
      - Closi 4y ago
        Yeah but ‘Turing complete languages’ have their own limitations compared to no code, like being comparatively slow to develop in. (In quotes because many/most no-code environments are Turing complete, but you still wouldn’t want to develop certain apps/logic in them)
- andrewmutz 4y ago
  > Why take something out of your toolbox? I completely agree with you and this is the crux of it. Even if you know how to code, there situations where a nocode tool (like retool) is the best tool for the job
- usrbinbash 4y ago
  > Why take something out of your toolbox? The problem isn't my toolbox. The problem is someone elses toolbox, who often isn't an engineer, when that someone hits the limits of that shiny, sparkly tool he put in his box. Because at that point, software engineers have to figure out how to interface some extension with that thing. Which may be easy. Or it may be next to impossible, because the tool usually doesn't have things like version control, standard interfaces other than outgoing HTTP (if it even has that), compatibility with common IDEs or the ability to unit test. Bonus points if it doesn't even store the box-and-line-diagrams in something vaguely grep-able like XML, but uses a proprietary binary format...or stores them on the vendors servers making them completely inaccessible other than through the vendors interface. Right tool for the right job? No problem with that. If it "empowers" someone to do something he couldn't do otherwise...great, full support. But as soon as someone wants me to interface my toolbox with it, I will demand that it offers the same qualities that I expect from every other tool that I use. Because these qualities aren't arbitrary, they evolved over decades of hard earned lessons in software engineering.
steveBK123 4y ago
I work for a guy now who basically picked up some coding in his 30s because he found the previous business team he was on was more successful because of it. His code isn't great, but he can express what he wants in giant SQL blobs and then we can build scalable solutions against basically his mockups. He can also unblock himself for a while with his own code while we build the real production flavor, etc. It's great because he is basically expressing his requirements in something that works. I think just like the coders should learn the business they work in, if the business learns some code.. everyone can be a lot happier. In the low code context I think if you can all agree to treat whatever is generated there as throwaway prototypes, then it can be a value add. Ie - instead of writing a 20 page document, I'm going to show you something that sort of works here. The pain comes from people thinking its going to replace developers, getting stuck, and then forcing the developers into the low-code tool too.
- sanderjd 4y ago
  Yep, I'm working with a guy on the business side who is amazing with Dash. It's the best example of a skill set being greater than the sum of its parts that I've seen.
- gghhzzgghhzz 4y ago
  CTE was a game changer for regular business people I work with being able to express what they want in SQL. SQL is still dreadful, apart from all the alternatives.
- runevault 4y ago
  In these scenarios these low code tools feel like the evolution of excel. How many times did people who couldn't write full on apps throw something together with some excel formulas to do a version of what they needed?
  - cudgy 4y ago
    This was (and may still be) the foundation of tax software: domain experts in each province specifying tax formulas in a spreadsheet with an interpreter that takes those formulas and translates it to code libraries in Java, C, C++, etc.
jffhn 4y ago
>some people think that the difficulty in implementing something is because it requires code On the contrary, being forced to clarify your thoughts under the constraints of a formal language, and be able to execute and test them, helps tremendously to figure out what you actually can do and want to do, even more so when the problem is complex (and excluding already well understood tasks).
jrm4 4y ago
Right? Broadly, it's kind of funny how people lump everything involving computer code together as if they are equally difficult. It's as if we lumped together the creation of everything "made of wood" as similar. Shelf, doll, table, boat, grandfather clock...
easterncalculus 4y ago
Somewhat related: https://www.levels.fyi/blog/scaling-to-millions-with-google-sheets.html https://www.levels.fyi/blog/scaling-to-millions-with-google-... Google Sheets is of course a little more than Excel, but the fact that large sites are still going this route and seeing success is legitimately impressive.
roncesvalles 4y ago
This articulates well something that's always been in my mind - code is just a precise expression of business logic. Programmers are actually business administrators making low granularity business decisions. You could make programming less complex but it doesn't obviate the need for making those low-granularity decisions -- you're just choosing to go with the "defaults".
- PaulDavisThe1st 4y ago
  I understand your point, but I really intensely dislike the term "business logic" when used as some sort of universal. A bunch of us write code that nothing to do with any "business logic", even if there is some other sort of set of workflow rules & design that need to apply. I write a DAW, and we face two major fundamental problems: 1. most DAW users don't use many features, but they do tend to use different sets of features. So if you want to be useful to lots of users, you need a LOT of features. 2. the corollary of (1) is that there are, unlike in "business logic" applications, oodles of workflows in use, and the application needs to support as many of them as possible without friction or bugs.
  - roncesvalles 4y ago
    I mean business logic in a very broad sense. You have your DAW and it does something. That's the abstract model. You could define what it does in a high-granularity sense (point 1), but you also need to define what it does at lower levels of granularity. What you define at those lower levels is still part of the the abstract model of the DAW. Hence it's "business logic". Whether you use a while-loop instead of a for-loop, that's not business logic but an implementation detail. Programmers make a ton of "implementation detail" type decisions but they also make a ton of decisions that affect the abstract definition of the thing, and these I define as "business logic".
    - PaulDavisThe1st 4y ago
      The point is there isn't really a "thing the program should do". If you compare to e.g. some sort of data entry or data analysis UI, you can describe the process the user is intended to follow, and that defines your "business logic". With creative apps, this "process the user is intended to follow" doesn't exist. We're not implementing the rules of an employer or a company, we're providing open-ended workflows for people who don't know what they're doing.
wruza 4y ago
also going all the way back to the original low code tool itself, spreadsheets. People really can build huge things with them. But after a certain degree of size and complexity, it’s more trouble than it’s worth to go with low code tools. The problem with spreadsheets is that they end up with 5 lines of formula code wrapping over a fullhd+ screen. If it was a regular code, which isn’t hard to write at all, they could grow much further and get help from professional developers. When I see that 5-line formula, I say “sorry, you have to figure it out by yourself”. What low-code should actually be is what we called RAD back in the day. Excel is a good idiom and a platform for doing things. But its language actually sucks. What regular people are afraid of is boilerplate and wheel-engineering, not code itself. I disagree with the second paragraph. Most of our “starter” complexity is highly incidental, in a sense that we always start in a forest, cold and naked.
intelVISA 4y ago
If you can translate business reqs into a (working) technical impl you're a programmer - the rest is semantics imo.
treeman79 4y ago
VB6 was a fantastic tool that managers with really bad programming skills could make useful fully functional products. I don’t know of a good equivalent replacement that people can use today with such a low entry level. Excel covers a lot for many people.

Closi 4y ago

Totally agree - right tool right job. Sometimes writing a full web application is the right solution, other times you just need a database with a front end and a low-code solution is best, other times an excel spreadsheet will be the right solution, and other times just physical process change is best. Why take something out of your toolbox?

pydry 4y ago
>other times you just need a database with a front end and a low-code solution is best Until you need it to do something slightly beyond its capabilities and then you are trapped with an app that needs to be rewritten with data that needs to be migrated in order to implement one small feature.
- Closi 4y ago
  That's the same thing with all technology choices though - if requirements change substantially you always risk a rewrite. If write a full-code application with all your logic in server-side .NET and suddenly your users have a requirement to use it offline, and then you are trapped with an app that needs to be rewritten with data that needs to be migrated in order to implement one feature This is all part of having a good level of intuition for what capabilities you are likely to need, and then picking appropriate technology.
  - pydry 4y ago
    There is a vast difference between the things which are blocked because youre not using a turing complete programming language and things which are blocked because of the nature of that language though. You'll probably run up against the former quite quickly. The latter possibly never.
    - Closi 4y ago
      Yeah but ‘Turing complete languages’ have their own limitations compared to no code, like being comparatively slow to develop in. (In quotes because many/most no-code environments are Turing complete, but you still wouldn’t want to develop certain apps/logic in them)
andrewmutz 4y ago
> Why take something out of your toolbox? I completely agree with you and this is the crux of it. Even if you know how to code, there situations where a nocode tool (like retool) is the best tool for the job
usrbinbash 4y ago
> Why take something out of your toolbox? The problem isn't my toolbox. The problem is someone elses toolbox, who often isn't an engineer, when that someone hits the limits of that shiny, sparkly tool he put in his box. Because at that point, software engineers have to figure out how to interface some extension with that thing. Which may be easy. Or it may be next to impossible, because the tool usually doesn't have things like version control, standard interfaces other than outgoing HTTP (if it even has that), compatibility with common IDEs or the ability to unit test. Bonus points if it doesn't even store the box-and-line-diagrams in something vaguely grep-able like XML, but uses a proprietary binary format...or stores them on the vendors servers making them completely inaccessible other than through the vendors interface. Right tool for the right job? No problem with that. If it "empowers" someone to do something he couldn't do otherwise...great, full support. But as soon as someone wants me to interface my toolbox with it, I will demand that it offers the same qualities that I expect from every other tool that I use. Because these qualities aren't arbitrary, they evolved over decades of hard earned lessons in software engineering.

steveBK123 4y ago

I work for a guy now who basically picked up some coding in his 30s because he found the previous business team he was on was more successful because of it. His code isn't great, but he can express what he wants in giant SQL blobs and then we can build scalable solutions against basically his mockups. He can also unblock himself for a while with his own code while we build the real production flavor, etc. It's great because he is basically expressing his requirements in something that works. I think just like the coders should learn the business they work in, if the business learns some code.. everyone can be a lot happier. In the low code context I think if you can all agree to treat whatever is generated there as throwaway prototypes, then it can be a value add. Ie - instead of writing a 20 page document, I'm going to show you something that sort of works here. The pain comes from people thinking its going to replace developers, getting stuck, and then forcing the developers into the low-code tool too.

sanderjd 4y ago
Yep, I'm working with a guy on the business side who is amazing with Dash. It's the best example of a skill set being greater than the sum of its parts that I've seen.
gghhzzgghhzz 4y ago
CTE was a game changer for regular business people I work with being able to express what they want in SQL. SQL is still dreadful, apart from all the alternatives.
runevault 4y ago
In these scenarios these low code tools feel like the evolution of excel. How many times did people who couldn't write full on apps throw something together with some excel formulas to do a version of what they needed?
- cudgy 4y ago
  This was (and may still be) the foundation of tax software: domain experts in each province specifying tax formulas in a spreadsheet with an interpreter that takes those formulas and translates it to code libraries in Java, C, C++, etc.

jffhn 4y ago

>some people think that the difficulty in implementing something is because it requires code On the contrary, being forced to clarify your thoughts under the constraints of a formal language, and be able to execute and test them, helps tremendously to figure out what you actually can do and want to do, even more so when the problem is complex (and excluding already well understood tasks).

jrm4 4y ago

Right? Broadly, it's kind of funny how people lump everything involving computer code together as if they are equally difficult. It's as if we lumped together the creation of everything "made of wood" as similar. Shelf, doll, table, boat, grandfather clock...

easterncalculus 4y ago

Somewhat related: https://www.levels.fyi/blog/scaling-to-millions-with-google-sheets.html https://www.levels.fyi/blog/scaling-to-millions-with-google-... Google Sheets is of course a little more than Excel, but the fact that large sites are still going this route and seeing success is legitimately impressive.

roncesvalles 4y ago

This articulates well something that's always been in my mind - code is just a precise expression of business logic. Programmers are actually business administrators making low granularity business decisions. You could make programming less complex but it doesn't obviate the need for making those low-granularity decisions -- you're just choosing to go with the "defaults".

PaulDavisThe1st 4y ago
I understand your point, but I really intensely dislike the term "business logic" when used as some sort of universal. A bunch of us write code that nothing to do with any "business logic", even if there is some other sort of set of workflow rules & design that need to apply. I write a DAW, and we face two major fundamental problems: 1. most DAW users don't use many features, but they do tend to use different sets of features. So if you want to be useful to lots of users, you need a LOT of features. 2. the corollary of (1) is that there are, unlike in "business logic" applications, oodles of workflows in use, and the application needs to support as many of them as possible without friction or bugs.
- roncesvalles 4y ago
  I mean business logic in a very broad sense. You have your DAW and it does something. That's the abstract model. You could define what it does in a high-granularity sense (point 1), but you also need to define what it does at lower levels of granularity. What you define at those lower levels is still part of the the abstract model of the DAW. Hence it's "business logic". Whether you use a while-loop instead of a for-loop, that's not business logic but an implementation detail. Programmers make a ton of "implementation detail" type decisions but they also make a ton of decisions that affect the abstract definition of the thing, and these I define as "business logic".
  - PaulDavisThe1st 4y ago
    The point is there isn't really a "thing the program should do". If you compare to e.g. some sort of data entry or data analysis UI, you can describe the process the user is intended to follow, and that defines your "business logic". With creative apps, this "process the user is intended to follow" doesn't exist. We're not implementing the rules of an employer or a company, we're providing open-ended workflows for people who don't know what they're doing.

wruza 4y ago

also going all the way back to the original low code tool itself, spreadsheets. People really can build huge things with them. But after a certain degree of size and complexity, it’s more trouble than it’s worth to go with low code tools. The problem with spreadsheets is that they end up with 5 lines of formula code wrapping over a fullhd+ screen. If it was a regular code, which isn’t hard to write at all, they could grow much further and get help from professional developers. When I see that 5-line formula, I say “sorry, you have to figure it out by yourself”. What low-code should actually be is what we called RAD back in the day. Excel is a good idiom and a platform for doing things. But its language actually sucks. What regular people are afraid of is boilerplate and wheel-engineering, not code itself. I disagree with the second paragraph. Most of our “starter” complexity is highly incidental, in a sense that we always start in a forest, cold and naked.

intelVISA 4y ago

If you can translate business reqs into a (working) technical impl you're a programmer - the rest is semantics imo.

treeman79 4y ago

VB6 was a fantastic tool that managers with really bad programming skills could make useful fully functional products. I don’t know of a good equivalent replacement that people can use today with such a low entry level. Excel covers a lot for many people.