4 ms·

That's what you would do because you can actually do it. But these tools are for people who don't know how to build those apps by writing actual code.

zozbot234 5y ago
The point of "writing actual code" is that it's the only way we know about of managing even middling amounts of complexity. If you "don't know how to do that", you shouldn't be attempting that sort of deployment in the first place. It's just not going to be sustainable. There are ways of writing less code over time, but they're based on the sort of solid abstractions that are really not that common. (This is how "high level" coding works.) But the typical "low code" or "no code" system is not built like that.
- Closi 5y ago
  Too much of the conversation ends up being about 'low code' vs 'writing actual code', but this is like arguing about if a hammer or a welding torch is a better tool. The reality is that some problems are fundamentally better suited to low code, and the solutions will be much simpler and easier to maintain if they are built as low-code (e.g. if I have MS Dynamics and want a new data-entry screen, doing it as a model-driven PowerApp is undeniably the best way to do this). Other problems will either be too complex, a poor fit, or simply not possible to implement within low-code tools. I'm not going to start developing a mobile game in PowerApps! I think the overall issue is "If all you have is a hammer, everything looks like a nail". The best thing is to recognise the relative strengths and weaknesses of the two approaches and pick the right tool for the job.
  - zozbot234 5y ago
    > a new data-entry screen We used to call those data entry screens "HTML forms". And hey, they're even text based so you can commit them to a version control!
    - Closi 5y ago
      In PowerApps they are called model-driven forms, and there is in-built version control! And although it's easy to write a HTML form, it tends to be slightly harder to write the code handling it on the backend to change the database, with full user/roll based authentication and validation - particularly if you are integrating it into your ERP. If the use case is a form to interact with Microsoft Dynamics, something built in PowerApps model-driven apps will be much more robust, quicker to develop and more secure than a html form with some custom handler.
  - q-big 5y ago
    > and the solutions will be much simpler and easier to maintain if they are built as low-code (e.g. if I have MS Dynamics and want a new data-entry screen, doing it as a model-driven PowerApp is undeniably the best way to do this). Counterexample: MS Access apps are often a maintenance nightmare.
    - Closi 5y ago
      > Counterexample: MS Access apps are often a maintenance nightmare. They end up being a maintenance nightmare because they are undocumented and flooded with poorly written VBA, which is hardly low-code. A non-VBA Access Database is trivial to maintain, but VBA is a full programming language, so if that's heavily used it's really maintaining a VB6 Winforms application, which isn't what we would now typically call 'low code' in terms of this article. (As an aside, I would actually personally argue that a completely undocumented MS Access database is actually slightly easier to maintain than an equally undocumented web application anyway. The reason these tend to be a 'maintenance nightmare' is that they are typically made in Shadow-IT rather than the technology itself which is very simple).
      - q-big 5y ago
        > The reason these tend to be a 'maintenance nightmare' is that they are typically made in Shadow-IT Low-code and no-code solutions are often created by shadow-IT.
        dragonwriter 5y ago
        > Low-code and no-code solutions are often created by shadow-IT. Heck, while it is phrased differently, enabling Shadow IT is an explicit selling point of low- and especially “no”-[0] code tools. Of course, Shadow IT isn’t the tools fault, it is the organization that segregates IT into a separate heirarchy often the whole way up until the C-Suite. If IT was a function integrated within each business unit empowering it, rather than external silo alternately constraining arbitrarily and granting favors, Shadow IT woudn’t be a thing. Shadow IT is a symptom of a broken relationship between IT and the broader organization. [0] but often not really “no”, just as Excel isn’t.
- gervwyk 5y ago
  Totally agree with this. For example hiding config in a GUI creates an excessive amount to problems at scale. The magic of find, replace, cope and paste is at the core of why code works well at scale. Writing less code should always be top of mind for any developer. But making the right abstraction decisions seems to be the true art of coding. The question then becomes can we write a low code framework that does this well? - best we try :)
  - js8 5y ago
    > The question then becomes can we write a low code framework that does this well? We ask mathematicians for help! https://math.mit.edu/~dspivak/teaching/sp18/7Sketches.pdf https://math.mit.edu/~dspivak/teaching/sp18/7Sketches.pdf
Closi 5y ago
> But these tools are for people who don't know how to build those apps by writing actual code. IMO assuming low-code is just for people who don't know how to code is missing the power of low-code in the ERP/CRM space, and how that will be applicable to more spaces in the future. Besides, I can program but I can also build a simple application in a low-code solution quicker and it will usually be more reliable without lots of testing. IMO saying low-code is for people who don't know how to write actual code is like saying a typewriter is for people who don't know how to write with a pen - they are two different tools to get a job done, and sometimes a pen is better and sometimes a typewriter is better.
tonyedgecombe 5y ago
I don't think that's the case, at least not completely. I worked with a low code product twenty years ago that was targeted at a narrow domain. In the right hands it was fantastic but it was useless as a crutch for people that couldn't even describe the problem they were trying to solve. The people that excelled with it were programmers and others who clearly had the ability to write software. The people that struggled were the ones that couldn't decompose a problem into its constituent parts, that didn't have sufficient attention to detail. It was a productive tool in the right hands, the only time we had problems were when it was mis-sold as a way to solve problems without needing problem solvers.

zozbot234 5y ago

The point of "writing actual code" is that it's the only way we know about of managing even middling amounts of complexity. If you "don't know how to do that", you shouldn't be attempting that sort of deployment in the first place. It's just not going to be sustainable. There are ways of writing less code over time, but they're based on the sort of solid abstractions that are really not that common. (This is how "high level" coding works.) But the typical "low code" or "no code" system is not built like that.

Closi 5y ago
Too much of the conversation ends up being about 'low code' vs 'writing actual code', but this is like arguing about if a hammer or a welding torch is a better tool. The reality is that some problems are fundamentally better suited to low code, and the solutions will be much simpler and easier to maintain if they are built as low-code (e.g. if I have MS Dynamics and want a new data-entry screen, doing it as a model-driven PowerApp is undeniably the best way to do this). Other problems will either be too complex, a poor fit, or simply not possible to implement within low-code tools. I'm not going to start developing a mobile game in PowerApps! I think the overall issue is "If all you have is a hammer, everything looks like a nail". The best thing is to recognise the relative strengths and weaknesses of the two approaches and pick the right tool for the job.
- zozbot234 5y ago
  > a new data-entry screen We used to call those data entry screens "HTML forms". And hey, they're even text based so you can commit them to a version control!
  - Closi 5y ago
    In PowerApps they are called model-driven forms, and there is in-built version control! And although it's easy to write a HTML form, it tends to be slightly harder to write the code handling it on the backend to change the database, with full user/roll based authentication and validation - particularly if you are integrating it into your ERP. If the use case is a form to interact with Microsoft Dynamics, something built in PowerApps model-driven apps will be much more robust, quicker to develop and more secure than a html form with some custom handler.
- q-big 5y ago
  > and the solutions will be much simpler and easier to maintain if they are built as low-code (e.g. if I have MS Dynamics and want a new data-entry screen, doing it as a model-driven PowerApp is undeniably the best way to do this). Counterexample: MS Access apps are often a maintenance nightmare.
  - Closi 5y ago
    > Counterexample: MS Access apps are often a maintenance nightmare. They end up being a maintenance nightmare because they are undocumented and flooded with poorly written VBA, which is hardly low-code. A non-VBA Access Database is trivial to maintain, but VBA is a full programming language, so if that's heavily used it's really maintaining a VB6 Winforms application, which isn't what we would now typically call 'low code' in terms of this article. (As an aside, I would actually personally argue that a completely undocumented MS Access database is actually slightly easier to maintain than an equally undocumented web application anyway. The reason these tend to be a 'maintenance nightmare' is that they are typically made in Shadow-IT rather than the technology itself which is very simple).
    - q-big 5y ago
      > The reason these tend to be a 'maintenance nightmare' is that they are typically made in Shadow-IT Low-code and no-code solutions are often created by shadow-IT.
      - dragonwriter 5y ago
        > Low-code and no-code solutions are often created by shadow-IT. Heck, while it is phrased differently, enabling Shadow IT is an explicit selling point of low- and especially “no”-[0] code tools. Of course, Shadow IT isn’t the tools fault, it is the organization that segregates IT into a separate heirarchy often the whole way up until the C-Suite. If IT was a function integrated within each business unit empowering it, rather than external silo alternately constraining arbitrarily and granting favors, Shadow IT woudn’t be a thing. Shadow IT is a symptom of a broken relationship between IT and the broader organization. [0] but often not really “no”, just as Excel isn’t.
gervwyk 5y ago
Totally agree with this. For example hiding config in a GUI creates an excessive amount to problems at scale. The magic of find, replace, cope and paste is at the core of why code works well at scale. Writing less code should always be top of mind for any developer. But making the right abstraction decisions seems to be the true art of coding. The question then becomes can we write a low code framework that does this well? - best we try :)
- js8 5y ago
  > The question then becomes can we write a low code framework that does this well? We ask mathematicians for help! https://math.mit.edu/~dspivak/teaching/sp18/7Sketches.pdf https://math.mit.edu/~dspivak/teaching/sp18/7Sketches.pdf

Closi 5y ago

> But these tools are for people who don't know how to build those apps by writing actual code. IMO assuming low-code is just for people who don't know how to code is missing the power of low-code in the ERP/CRM space, and how that will be applicable to more spaces in the future. Besides, I can program but I can also build a simple application in a low-code solution quicker and it will usually be more reliable without lots of testing. IMO saying low-code is for people who don't know how to write actual code is like saying a typewriter is for people who don't know how to write with a pen - they are two different tools to get a job done, and sometimes a pen is better and sometimes a typewriter is better.

tonyedgecombe 5y ago

I don't think that's the case, at least not completely. I worked with a low code product twenty years ago that was targeted at a narrow domain. In the right hands it was fantastic but it was useless as a crutch for people that couldn't even describe the problem they were trying to solve. The people that excelled with it were programmers and others who clearly had the ability to write software. The people that struggled were the ones that couldn't decompose a problem into its constituent parts, that didn't have sufficient attention to detail. It was a productive tool in the right hands, the only time we had problems were when it was mis-sold as a way to solve problems without needing problem solvers.