5 ms·

Low code initially works quite well until you hit the limits of the low-code framework. If you just need a throw-away proof of concept, or a personal utility, o

Low code initially works quite well until you hit the limits of the low-code framework. If you just need a throw-away proof of concept, or a personal utility, or the like, low-code solutions can be quite efficient. However, implementing anything significant that's expected to be extended and improved, particularly when there are users that request changes, improvements and new features, low-code "is like climbing a tree in order to reach the moon". You'll will very quickly run out of tree and further progress becomes almost impossible. To a lesser extent the same thing also occurs with web development frameworks, but the limits are less constraining and there are often mechanisms that allow you integrate your own code, that implements whatever it is that the framework doesn't provide. Low code, frameworks, and "build it totally from scratch", can all be a valid solutions, but the right choice often depends on a bunch of specific considerations (technology, user & quality expectations, organizational capabilities & constraints, etc.) My recommendation is to keep an open mind about alternative technologies and approaches, and to pick solutions that are appropriate for the environment in which they will be developed, extended and operated. And that requires experience, which you normally don't have in the early phase of your career (e.g. good judgement comes from experience, and experience comes from bad judgement)

brightball 2y ago
One of the perks of Rails is that Ruby itself makes it more compelling. When you need to get to something that the framework doesn’t expose, Ruby makes it easy to get to it without having to rewrite the framework, extend a class and replace it in multiple places or fork it just to use your modification. This applies to the entire gem ecosystem too. Over the years this ability has saved me numerous headaches with only a few lines of code. IMO it’s the real super power of Ruby.
- it_citizen 2y ago
  I agree. But with great powers comes great responsabilities.
- Gigachad 2y ago
  Ruby is my least favorite part of Rails by far. The lack of type checking makes every single gem and rails update extremely dangerous in ways that are incredibly difficult to predict. For example the redis gem updated to return an int from exists() instead of a bool like it did before. This doesn’t raise any exceptions because all ints work in if statements. They just always return true. Silently breaking all of the code using it. You can read all of the change logs and search your own code base, but will constantly run in to situations where another gems code is using the method that just changed. As well as the fact that almost every method has one param “options” where the available options are never listed in the documentation and are impossible to find without reading the source code. Rails itself I quite like for being an all inclusive framework that just works out of the box, but untyped languages should be avoided at all costs these days when we have much better options like typescript.
  - lazylester 2y ago
    "...but will constantly run in to situations where another gems code is using the method that just changed". I've worked with Rails for 20 years and haven't seen this. Have I just been really lucky? I'm sure your test suite showed the warnings about the Redis `exists()` change for many versions prior to its actually being changed, right?
    - Gigachad 2y ago
      I’ve worked on rails apps for a while now and on previous jobs it wasn’t so bad, but those were smaller apps. At the current company, almost every update manages to slip something through CI that blows up on production. Even with 30,000 rspec tests and tons of cypress tests. The CI is set up to raise exceptions on warnings, but I think it only applies to warnings raised by rails. I guess rails works alright at the start, but eventually your app gets so big that it becomes a nightmare to verify updates before they roll out.
      - jack_riminton 2y ago
        30,000+ tests and it can't detect breaking changes?
ksec 2y ago
>Low code initially works quite well until you hit the limits of the low-code framework. I wrote this a while ago. May be the future is a No Code tool with AI that generate enough of an App to allow Low Code edit with the help of AI while the whole App itself is still a full Ruby Rails App that allow Real Code modification in the future by professionals.
devjab 2y ago
I’ve spend a few decades in non-tech enterprise including 7 years in the public sector, and I’ve never seen a low-code solution work at all. Even extremely simple automation flows require at least some degree of software engineering. Looping isn’t intuitive at all, he’ll even conditions aren’t. What has completely changed the field is LLMs. We now have employees of every sort building small Python scripts which actually work. Even installing Python and getting it up and running is something the LLMs help with. Obviously almost all of it is terrible, and none of scale, but for 90% it, it never has to run outside the personal computers of the employees who write it. Now the challenge becomes keeping the knowledge (and scripts) when employees change jobs. Though to be fair, the knowledge bit was always a challenge.
- qsort 2y ago
  The second coming of Excel, basically.
  - Tarks 2y ago
    Shhhhhhhh. Do you have any idea how much I made in Fintech converting spreadsheets that'd exceeded the TA's ability to hack/keep it all in their head and/or quit? Favourite included a single cell that had, I am not kidding, something like 150+ nested if statements.. and there was a dateTime bug in it somewhere :D A friend did very well positioning himself as a data engineering consultant that could come in and quickly improve poorly thrown together data pipelines, wonder what the equivalent is for these :)
    - amichal 2y ago
      Wasn't fintech but was fin something. Several weeks into trying to port a Excel workbook with a zillion tabs, some VBscript from stackoverflow and other nastiness and being unable to replicate the results. I discovered the "consultant" who help them create this insane thing had turned on the "allow circular references"[1] option and choosen a number of iterations that "Seemed to make it work" Yay! for non-deterministic financial modeling. Also was really fun trying to explain to the folks who hired me why I couldnt get the results they wanted to see. [1] https://support.microsoft.com/en-us/office/remove-or-allow-a-circular-reference-in-excel-8540bd0f-6e97-4483-bcf7-1b49cd50d123 https://support.microsoft.com/en-us/office/remove-or-allow-a...
jstummbillig 2y ago
Low code tools are fantastic for people with unambitious software goals (not to be confused with unambitious company goals). A lot of burden is lifted off of the tool builder, simply, because there is so much stuff that has been decided for you and therefore a lot of things you can not do. But you have to really accept this limitation as a feature, just like you need to accept that inventing pieces or moves is not an option when you get frustrated during a match of chess. As soon as you fall into the coder mindset of "If only I could go one level down", you immediately switch into having 0 upside while having all of the downside. You fight the tool and then there's a ton of things that would in fact be simpler if you just wrote it starting from the correct level. I would argue, just as with coding, this is mostly a matter of discipline. Having boundaries is part of the real world problem solving. Being able to work within them is a skill.
cies 2y ago
> Low code initially works quite well until you hit the limits of the low-code framework. If you just need a throw-away proof of concept, or a personal utility, or the like, low-code solutions can be quite efficient. The same I'd say for dynamically typed languages (and their frameworks like Rails): initially works quite well until you hit the limits. Once your app is big and there is a team, the efficiency dwindles. Refactoring becomes really hard. Unit test for the rescue, but they also take time to write.
- dustingetz 2y ago
  at some point we need to take a step back and acknowledge that programming is not solved, no kind of language works particularly well at scale. Companies have been buying their way out by growing revenue/cash more quickly than tech debt, and those that fail to do that, stagnate and die.

brightball 2y ago

One of the perks of Rails is that Ruby itself makes it more compelling. When you need to get to something that the framework doesn’t expose, Ruby makes it easy to get to it without having to rewrite the framework, extend a class and replace it in multiple places or fork it just to use your modification. This applies to the entire gem ecosystem too. Over the years this ability has saved me numerous headaches with only a few lines of code. IMO it’s the real super power of Ruby.

it_citizen 2y ago
I agree. But with great powers comes great responsabilities.
Gigachad 2y ago
Ruby is my least favorite part of Rails by far. The lack of type checking makes every single gem and rails update extremely dangerous in ways that are incredibly difficult to predict. For example the redis gem updated to return an int from exists() instead of a bool like it did before. This doesn’t raise any exceptions because all ints work in if statements. They just always return true. Silently breaking all of the code using it. You can read all of the change logs and search your own code base, but will constantly run in to situations where another gems code is using the method that just changed. As well as the fact that almost every method has one param “options” where the available options are never listed in the documentation and are impossible to find without reading the source code. Rails itself I quite like for being an all inclusive framework that just works out of the box, but untyped languages should be avoided at all costs these days when we have much better options like typescript.
- lazylester 2y ago
  "...but will constantly run in to situations where another gems code is using the method that just changed". I've worked with Rails for 20 years and haven't seen this. Have I just been really lucky? I'm sure your test suite showed the warnings about the Redis `exists()` change for many versions prior to its actually being changed, right?
  - Gigachad 2y ago
    I’ve worked on rails apps for a while now and on previous jobs it wasn’t so bad, but those were smaller apps. At the current company, almost every update manages to slip something through CI that blows up on production. Even with 30,000 rspec tests and tons of cypress tests. The CI is set up to raise exceptions on warnings, but I think it only applies to warnings raised by rails. I guess rails works alright at the start, but eventually your app gets so big that it becomes a nightmare to verify updates before they roll out.
    - jack_riminton 2y ago
      30,000+ tests and it can't detect breaking changes?

ksec 2y ago

>Low code initially works quite well until you hit the limits of the low-code framework. I wrote this a while ago. May be the future is a No Code tool with AI that generate enough of an App to allow Low Code edit with the help of AI while the whole App itself is still a full Ruby Rails App that allow Real Code modification in the future by professionals.

devjab 2y ago

I’ve spend a few decades in non-tech enterprise including 7 years in the public sector, and I’ve never seen a low-code solution work at all. Even extremely simple automation flows require at least some degree of software engineering. Looping isn’t intuitive at all, he’ll even conditions aren’t. What has completely changed the field is LLMs. We now have employees of every sort building small Python scripts which actually work. Even installing Python and getting it up and running is something the LLMs help with. Obviously almost all of it is terrible, and none of scale, but for 90% it, it never has to run outside the personal computers of the employees who write it. Now the challenge becomes keeping the knowledge (and scripts) when employees change jobs. Though to be fair, the knowledge bit was always a challenge.

qsort 2y ago
The second coming of Excel, basically.
- Tarks 2y ago
  Shhhhhhhh. Do you have any idea how much I made in Fintech converting spreadsheets that'd exceeded the TA's ability to hack/keep it all in their head and/or quit? Favourite included a single cell that had, I am not kidding, something like 150+ nested if statements.. and there was a dateTime bug in it somewhere :D A friend did very well positioning himself as a data engineering consultant that could come in and quickly improve poorly thrown together data pipelines, wonder what the equivalent is for these :)
  - amichal 2y ago
    Wasn't fintech but was fin something. Several weeks into trying to port a Excel workbook with a zillion tabs, some VBscript from stackoverflow and other nastiness and being unable to replicate the results. I discovered the "consultant" who help them create this insane thing had turned on the "allow circular references"[1] option and choosen a number of iterations that "Seemed to make it work" Yay! for non-deterministic financial modeling. Also was really fun trying to explain to the folks who hired me why I couldnt get the results they wanted to see. [1] https://support.microsoft.com/en-us/office/remove-or-allow-a-circular-reference-in-excel-8540bd0f-6e97-4483-bcf7-1b49cd50d123 https://support.microsoft.com/en-us/office/remove-or-allow-a...

jstummbillig 2y ago

Low code tools are fantastic for people with unambitious software goals (not to be confused with unambitious company goals). A lot of burden is lifted off of the tool builder, simply, because there is so much stuff that has been decided for you and therefore a lot of things you can not do. But you have to really accept this limitation as a feature, just like you need to accept that inventing pieces or moves is not an option when you get frustrated during a match of chess. As soon as you fall into the coder mindset of "If only I could go one level down", you immediately switch into having 0 upside while having all of the downside. You fight the tool and then there's a ton of things that would in fact be simpler if you just wrote it starting from the correct level. I would argue, just as with coding, this is mostly a matter of discipline. Having boundaries is part of the real world problem solving. Being able to work within them is a skill.

cies 2y ago

> Low code initially works quite well until you hit the limits of the low-code framework. If you just need a throw-away proof of concept, or a personal utility, or the like, low-code solutions can be quite efficient. The same I'd say for dynamically typed languages (and their frameworks like Rails): initially works quite well until you hit the limits. Once your app is big and there is a team, the efficiency dwindles. Refactoring becomes really hard. Unit test for the rescue, but they also take time to write.

dustingetz 2y ago
at some point we need to take a step back and acknowledge that programming is not solved, no kind of language works particularly well at scale. Companies have been buying their way out by growing revenue/cash more quickly than tech debt, and those that fail to do that, stagnate and die.