Earlier quoted context omitted.
So many good points here, best summary of the problem of no code I've read yet. Whether you write lots of code or no code, all the principles you mentioned remain i.e. testing, deployment complexity, maintainability, rollback, release strategies etc. If you tried to do all that in a no code environment it would be horrendous. If you skip it, as a non engineer might, you're courting catastrophe. No code will often mak…
I think this argument against low-code is based on a misunderstanding of how most companies are staffed. Truth: in normal companies, there are never enough software developers to build everything that needs building Consequence: tons of processes and people get by as best they can, their never-prioritized project languishing in IT's backlog, often manually processing things that could be trivially automated Consequen…
Low-Code and the Democratization of Programming
91–98 of 98 posts
Re: Low-Code and the Democratization of Programming
#92Earlier quoted context omitted.
I think this argument against low-code is based on a misunderstanding of how most companies are staffed. Truth: in normal companies, there are never enough software developers to build everything that needs building Consequence: tons of processes and people get by as best they can, their never-prioritized project languishing in IT's backlog, often manually processing things that could be trivially automated Consequen…
Not really. I've granted that there is a middle ground, it's just that you have to draw the line at systems that actually need proper engineering eg where security or performance has serious real world consequences. It's a question of where you draw the line. Use this for appropriate use cases but beware of abusing this stuff.
I've seen stuff that has core-business, real world consequences, to the tune of affecting company's quarterly results, run off an Excel spreadsheet. And I don't think this is abnormal in large business land.
So the line shouldn't be drawn at "Is this system too important to trust to low-code?"
It should be drawn at "Is this system important to us?" + "If so, are we willing and able to assign development resources at it, to do it properly?" + "If not, what do we need from a low-code interim solution to keep it safe and maintainable?"
If we can't fix it properly, then it's counterproductive to enumerate the ways the fix we can apply is less than perfect.
Re: Low-Code and the Democratization of Programming
#93Earlier quoted context omitted.
I actually use FMP for a database at my wife's work. FMP is still shipping updates and new versions. Surprisingly you can pay to have your DB hosted on AWS. That said, it's very expensive.
Are there any FMP like low code products that would also allow user sign up/sign in? I believe the problem with Access/FMP were that they were single user or trusted user setups.
I don't know if you can create a "new user" flow in your app, but you can add/register users and assign them to permissions groups from the FMP admin dialog.
Re: Low-Code and the Democratization of Programming
#94Earlier quoted context omitted.
Not really. I've granted that there is a middle ground, it's just that you have to draw the line at systems that actually need proper engineering eg where security or performance has serious real world consequences. It's a question of where you draw the line. Use this for appropriate use cases but beware of abusing this stuff.
Every system should have proper engineering. Most systems need proper engineering. Few systems actually have proper engineering. I've seen stuff that has core-business, real world consequences, to the tune of affecting company's quarterly results, run off an Excel spreadsheet. And I don't think this is abnormal in large business land. So the line shouldn't be drawn at "Is this system too important to trust to low-cod…
I don't deny there's a place for no code, I'm just sceptical about intended uses. Not least because a lot of what is written are puff pieces by someone with an agenda. This is big business.
Re: Low-Code and the Democratization of Programming
#95> Another way of looking at low-code is to take an even bigger step back, and look at the history of programming from the start. Python is low-code relative to C++; C and FORTRAN are low-code relative to assembler; assembler is low-code relative to machine language and toggling switches to insert binary instructions directly into the computer’s memory. That is the most stupid thing I've read in a while.
First, it's not "low-code" or "no-code", it's high-level code vs. low-level code vs. non-traditional non-text-based code like labview. But it's still code, there's always the code.
Second, learning "code" or "coding" isn't the problem in democratizing "programming" in the first place. Code is the easy part. Software engineering, architecture, debugging & troubleshooting, logic, math, configuration management, project management - that stuff is the hard part. It's of absolutely no help to have a bunch of smart domain-experts happily "no-coding" away in matlab or labview or excel or ms. access and then stumbling right into the same bad engineering practices that you might find in struggling projects using traditional tools.
That's because we don't need "coders" or "programmers" at all. We need people to be engineers. And part of good engineering is picking the right tool and system to use, not jumping on the next over-hyped fad.
Re: Low-Code and the Democratization of Programming
#96The problem with many low-code platforms is three fold: - many over-promise and under deliver. Low code platforms are great for simple CRUD apps, defined automations, etc. - some, like Bubble, are anti-code to their own detriment - code is good, your platform was created with code - only a few, like Budibase [1], Tooljet [2], n8n [3] are open source. I cannot understand how users are willing to bet their data and pro…
Disclaimer: I am creator of Obsei
Re: Low-Code and the Democratization of Programming
#97The contributions of communities in the growth of programming languages is huge. If no-code/low-code is looking at a similar trajectory, open-source frameworks might prove to be the best options. Examples: ToolJet: https://github.com/ToolJet/ToolJet Obsei: https://github.com/obsei/obsei n8n: https://github.com/n8n-io/n8n
Re: Low-Code and the Democratization of Programming
#98All this posts miss the best low code environments of all time: Microsoft Access and FileMaker Pro. Unfortunately these two never made it to Internet era in big time and we have greatly come down from 90s RAD movement.
I still think Low-Code is a problem worth solving and it should start with spreadsheet like structure.
I am wondering if there are any Low-Code / No-Code solution for Web CRUD Apps? Something like Yahoo! Pipes...