4 ms·

A really good post - I think 'low/no' code generally gets a hard time on HackerNews, generally because it's place and application is misunderstood. The success

by Closi 6y ago

A really good post - I think 'low/no' code generally gets a hard time on HackerNews, generally because it's place and application is misunderstood. The success of PowerApps is a huge part of the Microsoft Dynamics appeal in the ERP space for instance - and they seem to be winning this segment very quickly on the back of it with tremendous growth. The fact a relatively inexperienced user can create a new phone app that is fully integrated into the company ERP is a real point of difference.

thrower123 6y ago
I would rather write Spring beans or jam forks in my hand than try to glom Flow/PowerAutomate lego blocks together. When I have managed to staple together a workflow, it routinely stops working after a couple weeks. It's going to keep a lot of people employed keeping those things going as the platform shifts underneath you every six months, and/or yanking the Goldberg machines out into real code.
- darkhorse13 6y ago
  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 6y 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 6y 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 6y 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 6y 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 6y 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 6y 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 6y 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.
- deleted 6y ago
  [deleted]
void_mint 6y ago
You'd never ask someone that fixes their own car what they find valuable in a good mechanic. You shouldn't ask a group of software developers what they find valuable in a no-code toolset.
- convolvatron 6y ago
  no one else knows how much useless time wasting boilerplate crap goes into programming. or how fragile these systems really are. I'd be happy to lose my economic position as a possessor of arcane skills if we can stop trying to construct multistory buildings out of mud and learn to frame walls properly.
valenterry 6y ago
It's more like you can often hear people claim that no-code will replace code. Which to some degree is true - but not in the way it is sold. Most devs already use no-code an low-code and they know when to use what.

by Closi 6y ago

thrower123 6y ago

I would rather write Spring beans or jam forks in my hand than try to glom Flow/PowerAutomate lego blocks together. When I have managed to staple together a workflow, it routinely stops working after a couple weeks. It's going to keep a lot of people employed keeping those things going as the platform shifts underneath you every six months, and/or yanking the Goldberg machines out into real code.

darkhorse13 6y ago
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 6y 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 6y 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 6y 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 6y 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 6y 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 6y 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 6y 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.
deleted 6y ago
[deleted]

void_mint 6y ago

You'd never ask someone that fixes their own car what they find valuable in a good mechanic. You shouldn't ask a group of software developers what they find valuable in a no-code toolset.

convolvatron 6y ago
no one else knows how much useless time wasting boilerplate crap goes into programming. or how fragile these systems really are. I'd be happy to lose my economic position as a possessor of arcane skills if we can stop trying to construct multistory buildings out of mud and learn to frame walls properly.

valenterry 6y ago

It's more like you can often hear people claim that no-code will replace code. Which to some degree is true - but not in the way it is sold. Most devs already use no-code an low-code and they know when to use what.