The one thing I worry about is security. How do you make low code tools flexible enough to be powerful while retaining security? On the other hand, maybe for the use cases that are well supported, these tools could provide security by default instead of relying on individual engineers to get it right.
A lot of it will be pushed down the stack into infrastructure. Infrastructure typically tails software, so over the next decade I would expect to see shifts in the infrastructure to accommodate this.
For example, I think we'll start to see more fine-grained ACLs in databases combined with passthrough authentication from the webapp. So the nocode app is basically just a layout engine that passes a query and your Okta token (or whatever) to the database, which runs the query and filters out results you personally can't access, and then nocode app formats it (basically, in a naive implementation).
IT gets to maintain control of the ACLs, and permissions become seamlessly uniform across applications. Marketing doesn't have to talk to IT get to credentials for the database and talk about security, they just set up a new app and the database makes sure that users are allowed to access that data.
That will also cause a cottage industry of tools for managing those permissions to spring up.
I would keep a serious eye on Microsoft in this space. Active Directory + SQL Server gives them serious inroads into major companies for something like this. Sharepoint is also already in the same vein. If they bought out a nocode platform, replaced Sharepoint with it and integrated the ACLs for AD and SQL Server, they could have a really compelling product in this space. It would be a perfect add-on product for Office 365, and the billing is already set up for a lot of companies.
I'd say Microsoft already has this with Dataverse/Power platform? It runs on Azure SQL Server but it is not exposed directly nor uses SQL server's ACL. Instead, the available access points -- mainly its web API -- honor the permission system configured on the platform, whether it's coming from apps themselves, custom JS code or reporting tools like PowerBI. Users are of course AD users.
Model-driven apps on Dataverse are exactly how you'd imagine MS Access if rebuilt as a SaaS product, and they integrate with Office in various ways. One Azure tenant gets one Dataverse database-- it's certainly intended to host multiple apps sharing the database.
Main problem is that building meaningful LOB applications on this type of low code platform is difficult. Works well for a toy project, or ends up being engineered solutions maintained by IT -- neither hitting the sweet spot mark. I guess general purpose low code is hard.
> For example, I think we'll start to see more fine-grained ACLs in databases combined with passthrough authentication from the webapp. So the nocode app is basically just a layout engine that passes a query and your Okta token
I think you can set that up with Postgres using row-level security and a generic "REST to SQL" frontend whose name escapes me. Harder business logic can go in stored procedures, which Postgres allows you to in a range of languages AFAIK. It seems like a great architecture to me, and it should also be some kind of simple to wrap a generator around it with a nice UI.
One of the important issues that the no-code world hasn't really come to grips with is security. Generally speaking, you have similar security issues (not exactly the same as there are no buffer overflows or js-eval/java-object injection attacks) but the code is being written by non-experts. That means all the subtle problems of faulty business logic in which end users or third parties are given too much control is going to bite you bigly.
Moreover, it's a myth that "no-code" code is easier to read or less buggy than traditional code. Moreover the lack of propery IDE support, often improper version control, and difficulty of extracting the no-code from the platform for proper analysis makes it very hard to audit in a systematic way. And the existing security tooling can't understand it. We are going to end up with piles of this stuff, often highly privileged code, written by non-experts, running on important high value systems.
All 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.
My first 'programming' job (around 1996-97) was doing Lotus Notes and Domino development. It's sad that Notes is mostly remembered as a really shitty email client[0] these days. The place I worked at had built it's entire workflow and document handling system in Notes/Domino, including an easy to use web client for the users using *nix workstations. It was in incredibly productive and easy to use environment that in many ways I've yet to see an equal to.
[0] ironically, the one thing we didn't use Notes for was email.
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.
FMP supports multi-user setups. You can even use external auth servers including Google login now.
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.
I got into real software development by writing a inventory management tool using MS Access back in the day.
It worked great! The application even looked almost like a normal Windows app. I wrote all of it by myself without knowing much coding (though I did write lots of VBA).
The thing I'm finding hard to get my head around is people who are arguing that various languages such as COBOL or Python are, or might be considered low code or no code.
To anyone who needs to hear this: if it's code based programming then it's not no-code or low-code - it's code.
Well, the goal of COBOL was to make something that everyone could use, so that professional programmers would be obsolete. It didn't succeed, and it doesn't look like "no code" to us today, but the goal was the same.
But it's never really "no code". There's always "code", because you always have to tell the system what you want the program to do. However you tell it that, that description becomes the code.
COBOL and 'modern' Fortran (aka FORTRAN 66) where very much designed with the goal of making programming something that 'everybody' could do without having to learning about actual programming and computers and all that 'boring' stuff.
Each one involves telling your computer some logic, but on the left you have to be much more detailed and the computer makes fewer assumptions than on the right. Is Hasura Code or No Code™? I write some SQL or a GraphQL query, but I also click around and set permissions and relationships in a GUI.
Let me tell you: no/low-code solutions can be just as hard as if not harder than actual code in some cases. One of the more difficult engineering solutions I have had to implement in my career was with a tool called Tasktop, which synchronizes different requirements analysis tools like Jira, Jama, GitHub Issues, etc. No actual code is involved (unless you need to add customization scripts), but you definitely want experienced engineers creating these integrations, as there are a great deal of software engineering concepts that need to be understood in order to understand and create successful integrations. So “democratization” of programming is misleading for low/no-code solutions, as non-programmers will quickly find themselves in trouble and eventually hand off the solution to a an actual software engineer.
It’s not that low code isn’t hard, it’s that it isn’t code. Which for the life of me I will never understand. But I’ve seen entire businesses run on linked spreadsheets with formulas that would melt your brain. All built by people terrified of “code”.
Yeah, my face twitches whenever I see "no-code" solutions erect edifices of loops, conditionals, workflows, formulae, versioning and clever IDEs. I wonder if whoever POs this stuff is just oblivious to just how deep this rabbit hole of turing completeness goes.
It's bad enough when ansible does conditionals and loops with YAML. It's 10x worse when somebody thought they'd made the process easier because you have to drag and drop a box. There comes a point when most of these systems should just hand over control to a popular programming language with decent tooling OR a person and they almost always fly right past it.
> 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.
> That is the most stupid thing I've read in a while.
Arrogance.
It takes 10 lines of Python to compute a multiplicative inverse mod p, using arbitrary precision integers. [1] Try doing the same thing with nothing but x86 assembly and Volume 2 of Knuth's AOCP.
arguably, higher level language use higher level general code features, where-as no/lo-code solutions are using specialised/domain features.
This would make them similar to a framework like chef/ansible/puppet that requires a large library of "knowledge" on how to do various things (all written in traditional low/high-level general code).
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.
I've seen "low code" and "no code" solutions running at huge enterprises and it always inevitably ends up resembling a house of cards.
Proponents often cite how much quicker they can ship things and how it lets users define and automate their own workflows without waiting for engineers. The reality is that these time savings come by cutting corners from the development cycle. Because you're not doing "code", the code review step gets skipped. The authoring of automated test suites get skipped. The authoring of performance regression testing gets skipped. There's no waiting for things to bake in non-prod environments because people are changing settings directly on prod. No ones doing phased deployments with automated rollbacks here in these low code and no code environments. No design reviews mean you get solutions that are the absolute worst hacks.. Why go through the work of making "priority" a first class property on your ticket type when you can just string scan for "high" | "medium" | "low" on case titles when doing assignments?
Engineering teams could also move fast if they just threw maintainability to the wind. There's a reason they don't. If you do things the right way in these low/no code environments, the complexity is even worse, because the features are so half-baked that you can't setup proper safeguards without doing crazy amounts of escape-hatches.
Yeah, the biggest flaw with the low/no code solutions is that end users want, and get, access to how the workflow works and/or it ends up this giant hero workflow handling every single possible scenario.
Best to keep the task simple, pick up the response, do some sort of identification, pass on it to where it should go. That's it. Let the next destination handle more stuff.
In my experience there is one situation where no code shines, namely, in enterprise support and deployment assisting software.
I've worked at a company that sold products to enterprise. There you have programmers writing complex features but you also have complex per-client requirements. Basically, software engineers maintained a nocode product that support / solution engineers use (not so much end users). So yes, there is a real programmer in the loop, but surprisingly, things also often get done without involving this programmer.
From a coding perspective taking over these houses of cards are my favorite kind of project. If the spreadsheet (or whatever) is used to build a system that people start relying upon then the proof of concept is already done, the underlying domain model is fleshed out and the task prioritization is obvious.
Greenfield projects where requirements are vague, priorities are vague, the underlying domain model is vague and the need for the project to exist at all is dubious bug the shit out of me.
One of the most successful companies I ever worked at kickstarted many new business processes with a few guys importing, munging and exporting data from a spreadsheet and sending emails. It was manual and often repetitive. But, all the iteration happened in the background until they nailed down what was needed and then came to me with a set of crystal clear, validated requirements.
It was quite a contrast to all of those other companies where I was given a feature to write that took a week to knock out because a powerful customer said it would be cool to have. Inevitably, even they only played with it for 5 minutes before never using it again and nobody else even touched it once.
Or the other companies that went to the other extreme and treated random excel spreadsheets as fully fledged production systems that would trigger catastrophe if you looked at them funny.
I can't help but feel that there's a sweet spot somewhere here that most people (& low code companies) miss.
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 make little sense for a lot of "proper" software if you want something maintainable, extensible, safe, performant (add other engineering principles here). It's probably very useful for non devs to build tools and cobble things together, in a similar fashion to how Excel can replace certain programming tasks. Just don't build your whole system from these things.
I think it's important that people respect the limits of these, no doubt useful, tools. We should also respect us software engineers and understand why we do things in the way we do. It might seem too complex but you might be suprised how complex, potentially unsafe and limiting the alternatives can be.
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
Consequently this isn't about a choice between (traditional software development with all the trimming) vs (low-code). It's a choice between (nothing/Excel) vs (low-code).
And given that reality, I'd argue that moving to a well-integrated, gutter-guards-in-place, documented low-code system is a HUGE win for the company as a whole.
And sure, you can say "It isn't this or that" (that should be there in well designed software). But it's also a helluva lot better than what they were running their part of the company on before.
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-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.
You said it really, we're already drowning in dodgy systems code or no code. I'm just concerned to not make the problem worse with an even more powerful way to cause a disaster. Think the excel spreadsheet powering the quarterly results on steroids.
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.
It turns into a house of cards even when professionals use it.
Oracle Apex is a great tool for simple CRUD and reporting apps. But as systems grow big, you start to have complex flows, integrations with other tools (for file conversion, image manipulations, etc). and it becomes a big mess.
I been at one very large enterprise for the last 15 years; the amount of low/no code apps I've been through is...well you know when neo is in the matrix, he is shown the previous matrix versions by the architect? its that feeling, but in this case there is no version of reality where there is a win. The biggest problem I see even if this were to work, is that you don't really want non-developers using these tools. Who's to blame when the low/no code user makes a booboo ? These people typically don't want this burden, so I've always seen it pushed back to a developer...and the requests are usually beyond the scope of the low/no code tool such that it eventually always becomes a worse burden for devs than code
If you use this stuff right -- citizen-developers should be developing their own work.
Or at most, the work of their immediate group / team.
Who's to blame when the low/no code makes a booboo? The citizen-developer. And who fixes it? The citizen-developer. And who can fix it, because they already know how to do the work manually? The citizen-developer!
And, most critically, who is then incentivized to correct their own low/no code so it doesn't break again? The citizen developer.
The central organizational anti-pattern around this is "users build + IT maintains." Just... don't do that, or allow it. Make it clear when they get this capability, that they're responsible for fixing issues, and that IT will only advise.
And have that talk with their VP up front, so that when he or she tries to escalate because they have an "Oh @&$+" outage, you let them suffer long enough to hurt, before pitching in.
And then after the incident is over, you return with "So one way we prevent this on the other side of the house is {cvs/testing/environments/etc}..." And there's a chance they listen to you, because it's a solution to a problem they just had.
I think "low code" and "no code" just like making module. It simplifies the unlimited possibilities from code to a pre-compose and limited modules.
As you entering a restaurant, and you see the menu all the material is available to customize but having 1000 options. And you find there are a few default combos beside that. I don't think most of people will choose "customize" after they fully understand all the options.
I guess 80% people only need a basic functions. To engineer, that's a simple work. But to people who cannot code, that's extremely hard.
Also I think if low code and no code industry are more steady. It'll more like the traditional operations.
There're upstream, midstream and downstream. (Low/No code probably will be upstream or midstream) They need to take care about the QA & QC instead of normal software development flow. Because one mistake will affect all the downstream used.
What I'm generally amazed by is MatLab. They went from a general Math IDE to being an actual physics simulation environment...that now transpiles the symbolic flow based programming view to an external C-compatible library.
With this solution they are the only alternative, dominating whole industries with it. There are so many engineers with a no-coding background that literally build programs that end up as parts of firmwares on controllers...through MatLab.
Whether that's good or not (from the security point of view) is up for discussion. But I'm kind of amazed by the "compiler pipeline" that they achieved.
Imagine something like this combined with LLVM and an LSP based backend that also integrates a no-code way to implement fuzz and unit tests.
> Matlab isn’t umm... no code! It’s a programming language
All low-/no-code solutions are programming languages. Some of them are visual and lots of them have limited tooling support outside of a narrow solution stereotype, and they tend to defy superficial expectations about programming languages, but they all are programming in one form or another.
What if i tell you, code is the "no code" tool itself.
Why ?
You of course could run any code with assembly or machine language, but now we have high level programming languages, it's because we want "low-code", or "low machine-code".
The point is we want to map business problems/solutions into machine, code is just a "no code" tool which allows u to do that.
Yep. The problem is not that that programming languages are create an undemocratic force field around programming, it's that only very few people can efficiently translate any sort of requirements into any sort of machine-comprehensible instructions, doesn't matter if it's code, excel formulas, multitude of ERP checkboxes or something else.
The high demand and pay of the last few decades brought a lot of people into trying to be those few but it looks like the percentage of the "worthy" people remains as low as it was decades ago and move from Fortran to lowcode did nothing.
The issue is how the education system and teachers don't know the principles behind programming. They teach Algebra but they can't apply that knowledge to programming.
The challenge of programming is not really about writing in a programming language - it's about thinking, problem solving, and organization.
What low/no-code does is remove the setup and tooling barrier. I believe it's this barrier which scares most people away from programming. After all, even as an experienced software developer, I find some languages more intimidating because of the many tooling choices and setup options required before one can actually do something useful (front end development, anyone?).
Ruby on Rails did this for web development 20 years ago. It's way more complex now (partly because our expectations and desires are so much more complex), but when it was new it was essentially low-code compared to alternatives. And just with modern low-code systems, people who aren't good at thinking or structuring often create bad or unreliable things.
I'm sure more than a few of us have seen some of the monstrosities created by users with Excel. On the other hand, some non developers have created brilliant solutions in Excel. The same will be true of official no-code tools.
Where no-code can really benefit most, is by allowing some end users to attempt to solve their own problems. Chances are they won't end up with complete solutions, but they may end up with a clearer picture of what it is they want; and then they can go to professional developers and better communicate their needs. Maybe we'll end up throwing away less work as our solutions will better match the users' needs.
Exactly that. Also in my expereince as a Data Science consultant was that by far the best approach was to just rebuild what they attempted in excel in python. Also now that I think of it Excel is the original low code solution haha
This came up in the thread on Bank Python (last week?). These systems have frameworks for implementing Directed Acyclic Graphs of functions in Python to simplify migrating Excel workflows into peer reviewed, version controlled code.
I'm surprised how infrequently this comes up, given the massive usage of Excel in the business world; low-code/no-code is always discussed as if it's something new. Non-programmers in corporate America have been building excel applications for decades. You'd be surprised and a little scared by how many business critical processes depend on an excel workbook stored on a sharepoint somewhere.
Interestingly enough, Excel in many ways is also a sort of functional programming for the masses. Excel functions are (mostly) pure. Columns are sort of immutable, and you tend to build applications as collections of smaller functions composed together as you might in Lisp.
From my seat on business side it's becoming increasingly harder to source engineering talent as quickly as we could before so I expect this will drive further proliferation of nocode solutions to business asks.
The 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.
For me, the low code perspective is a little different.
I think that no/low code is the secret end goal for any B2B line of business product. You eventually want to be able to have sales engineers directly setting up your products for customers, with developers standing by to support or enhance the shared code pile. You never want to be in a situation where you need 1 developer and code pile per customer when you are trying to capture an entire market segment with hundreds or thousands of businesses.
Once you figure out all the likely paths through the jungle, you can expose configuration and scripting at the various decision points.
Our specific flavor of "low" code leverages SQL and projections of business state to allow for very precise tuning of certain logic. Being able to employ SQL to solve problems implies a very intimate understanding of the problem domain. You have to do battle with the business and iterate the model until you know 99% of it will never have to change. Anything less than this is walking across quicksand, as changes to schemas per already-configured customers quickly turns into a nightmare factory of regressions and otherworldly suffering.
My experience has been the complexity is still there somewhere. Just not in the form of what we normally refer code. Often pushed down to the database in the form of bloated procedures and views. If it is not in the application layer it is "low-code".
Democratization of code will be the same as the democratization of medicine: anyone can go to a pharmacy and buy aspirin, ibuprofen, vitamins, etc. That doesn't mean physicians are jobless. Also if you have some serious problem or disease you shouldn't self medicate, but get professional treatment.
Am I the only one here who remembers MS Access? It was a great no-code/low code product that created silos of information in many organizations and it was a real PITA to transfer it to other technologies.
The advantage in MS Access was that it was part of the MS ecosystem and used VBA which is well documented. What will happen when you'll want to transfer something you've made in today no-code solutions to another platform?
I've seen this in different organisations: an accountant writes an MS Access app and when he cannot handle it anymore, he hands it over to IT (which is always so slow to provide solutions because they keep worrying about security, interoperability, consistency, and such).
One such app had in all its tables a column called "useless". It turns out it was the primary key. The author didn't know what it was for and didn't figure out from its name that it was important. There were also foreign keys referring to the description columns, not the primary key column (which was useless, after all).
In one instance, I saw an IT manager being asked for support for an app he had never heard of. It was another attack of the coding accountant! I call it code and run.
Newer solutions which use abstraction layers like postgREST will hopefully result in easier migration down the road - but I doubt most products/projects use such a thing.
97 comments
[ 3.5 ms ] story [ 185 ms ] threadFor example, I think we'll start to see more fine-grained ACLs in databases combined with passthrough authentication from the webapp. So the nocode app is basically just a layout engine that passes a query and your Okta token (or whatever) to the database, which runs the query and filters out results you personally can't access, and then nocode app formats it (basically, in a naive implementation).
IT gets to maintain control of the ACLs, and permissions become seamlessly uniform across applications. Marketing doesn't have to talk to IT get to credentials for the database and talk about security, they just set up a new app and the database makes sure that users are allowed to access that data.
That will also cause a cottage industry of tools for managing those permissions to spring up.
I would keep a serious eye on Microsoft in this space. Active Directory + SQL Server gives them serious inroads into major companies for something like this. Sharepoint is also already in the same vein. If they bought out a nocode platform, replaced Sharepoint with it and integrated the ACLs for AD and SQL Server, they could have a really compelling product in this space. It would be a perfect add-on product for Office 365, and the billing is already set up for a lot of companies.
Model-driven apps on Dataverse are exactly how you'd imagine MS Access if rebuilt as a SaaS product, and they integrate with Office in various ways. One Azure tenant gets one Dataverse database-- it's certainly intended to host multiple apps sharing the database.
Main problem is that building meaningful LOB applications on this type of low code platform is difficult. Works well for a toy project, or ends up being engineered solutions maintained by IT -- neither hitting the sweet spot mark. I guess general purpose low code is hard.
I think you can set that up with Postgres using row-level security and a generic "REST to SQL" frontend whose name escapes me. Harder business logic can go in stored procedures, which Postgres allows you to in a range of languages AFAIK. It seems like a great architecture to me, and it should also be some kind of simple to wrap a generator around it with a nice UI.
Moreover, it's a myth that "no-code" code is easier to read or less buggy than traditional code. Moreover the lack of propery IDE support, often improper version control, and difficulty of extracting the no-code from the platform for proper analysis makes it very hard to audit in a systematic way. And the existing security tooling can't understand it. We are going to end up with piles of this stuff, often highly privileged code, written by non-experts, running on important high value systems.
Frankly, it's a nightmare.
Far, far ahead of its time.
[0] ironically, the one thing we didn't use Notes for was email.
Surprisingly you can pay to have your DB hosted on AWS. That said, it's very expensive.
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.
It worked great! The application even looked almost like a normal Windows app. I wrote all of it by myself without knowing much coding (though I did write lots of VBA).
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...
To anyone who needs to hear this: if it's code based programming then it's not no-code or low-code - it's code.
Put more simply:
code != no-code
But it's never really "no code". There's always "code", because you always have to tell the system what you want the program to do. However you tell it that, that description becomes the code.
<--Assembly----C----Scala----Django----Hasura----Bubble-->
Each one involves telling your computer some logic, but on the left you have to be much more detailed and the computer makes fewer assumptions than on the right. Is Hasura Code or No Code™? I write some SQL or a GraphQL query, but I also click around and set permissions and relationships in a GUI.
It's bad enough when ansible does conditionals and loops with YAML. It's 10x worse when somebody thought they'd made the process easier because you have to drag and drop a box. There comes a point when most of these systems should just hand over control to a popular programming language with decent tooling OR a person and they almost always fly right past it.
That is the most stupid thing I've read in a while.
Arrogance.
It takes 10 lines of Python to compute a multiplicative inverse mod p, using arbitrary precision integers. [1] Try doing the same thing with nothing but x86 assembly and Volume 2 of Knuth's AOCP.
It's a useful, humbling exercise.
[1] https://karpathy.github.io/2021/06/21/blockchain/
This would make them similar to a framework like chef/ansible/puppet that requires a large library of "knowledge" on how to do various things (all written in traditional low/high-level general code).
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.
Proponents often cite how much quicker they can ship things and how it lets users define and automate their own workflows without waiting for engineers. The reality is that these time savings come by cutting corners from the development cycle. Because you're not doing "code", the code review step gets skipped. The authoring of automated test suites get skipped. The authoring of performance regression testing gets skipped. There's no waiting for things to bake in non-prod environments because people are changing settings directly on prod. No ones doing phased deployments with automated rollbacks here in these low code and no code environments. No design reviews mean you get solutions that are the absolute worst hacks.. Why go through the work of making "priority" a first class property on your ticket type when you can just string scan for "high" | "medium" | "low" on case titles when doing assignments?
Engineering teams could also move fast if they just threw maintainability to the wind. There's a reason they don't. If you do things the right way in these low/no code environments, the complexity is even worse, because the features are so half-baked that you can't setup proper safeguards without doing crazy amounts of escape-hatches.
Best to keep the task simple, pick up the response, do some sort of identification, pass on it to where it should go. That's it. Let the next destination handle more stuff.
I've worked at a company that sold products to enterprise. There you have programmers writing complex features but you also have complex per-client requirements. Basically, software engineers maintained a nocode product that support / solution engineers use (not so much end users). So yes, there is a real programmer in the loop, but surprisingly, things also often get done without involving this programmer.
Greenfield projects where requirements are vague, priorities are vague, the underlying domain model is vague and the need for the project to exist at all is dubious bug the shit out of me.
One of the most successful companies I ever worked at kickstarted many new business processes with a few guys importing, munging and exporting data from a spreadsheet and sending emails. It was manual and often repetitive. But, all the iteration happened in the background until they nailed down what was needed and then came to me with a set of crystal clear, validated requirements.
It was quite a contrast to all of those other companies where I was given a feature to write that took a week to knock out because a powerful customer said it would be cool to have. Inevitably, even they only played with it for 5 minutes before never using it again and nobody else even touched it once.
Or the other companies that went to the other extreme and treated random excel spreadsheets as fully fledged production systems that would trigger catastrophe if you looked at them funny.
I can't help but feel that there's a sweet spot somewhere here that most people (& low code companies) miss.
No code will often make little sense for a lot of "proper" software if you want something maintainable, extensible, safe, performant (add other engineering principles here). It's probably very useful for non devs to build tools and cobble things together, in a similar fashion to how Excel can replace certain programming tasks. Just don't build your whole system from these things.
I think it's important that people respect the limits of these, no doubt useful, tools. We should also respect us software engineers and understand why we do things in the way we do. It might seem too complex but you might be suprised how complex, potentially unsafe and limiting the alternatives can be.
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
Consequently this isn't about a choice between (traditional software development with all the trimming) vs (low-code). It's a choice between (nothing/Excel) vs (low-code).
And given that reality, I'd argue that moving to a well-integrated, gutter-guards-in-place, documented low-code system is a HUGE win for the company as a whole.
And sure, you can say "It isn't this or that" (that should be there in well designed software). But it's also a helluva lot better than what they were running their part of the company on before.
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.
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.
Oracle Apex is a great tool for simple CRUD and reporting apps. But as systems grow big, you start to have complex flows, integrations with other tools (for file conversion, image manipulations, etc). and it becomes a big mess.
If you use this stuff right -- citizen-developers should be developing their own work.
Or at most, the work of their immediate group / team.
Who's to blame when the low/no code makes a booboo? The citizen-developer. And who fixes it? The citizen-developer. And who can fix it, because they already know how to do the work manually? The citizen-developer!
And, most critically, who is then incentivized to correct their own low/no code so it doesn't break again? The citizen developer.
The central organizational anti-pattern around this is "users build + IT maintains." Just... don't do that, or allow it. Make it clear when they get this capability, that they're responsible for fixing issues, and that IT will only advise.
And have that talk with their VP up front, so that when he or she tries to escalate because they have an "Oh @&$+" outage, you let them suffer long enough to hurt, before pitching in.
And then after the incident is over, you return with "So one way we prevent this on the other side of the house is {cvs/testing/environments/etc}..." And there's a chance they listen to you, because it's a solution to a problem they just had.
As you entering a restaurant, and you see the menu all the material is available to customize but having 1000 options. And you find there are a few default combos beside that. I don't think most of people will choose "customize" after they fully understand all the options.
I guess 80% people only need a basic functions. To engineer, that's a simple work. But to people who cannot code, that's extremely hard.
There're upstream, midstream and downstream. (Low/No code probably will be upstream or midstream) They need to take care about the QA & QC instead of normal software development flow. Because one mistake will affect all the downstream used.
With this solution they are the only alternative, dominating whole industries with it. There are so many engineers with a no-coding background that literally build programs that end up as parts of firmwares on controllers...through MatLab.
Whether that's good or not (from the security point of view) is up for discussion. But I'm kind of amazed by the "compiler pipeline" that they achieved.
Imagine something like this combined with LLVM and an LSP based backend that also integrates a no-code way to implement fuzz and unit tests.
All low-/no-code solutions are programming languages. Some of them are visual and lots of them have limited tooling support outside of a narrow solution stereotype, and they tend to defy superficial expectations about programming languages, but they all are programming in one form or another.
Why ?
You of course could run any code with assembly or machine language, but now we have high level programming languages, it's because we want "low-code", or "low machine-code".
The point is we want to map business problems/solutions into machine, code is just a "no code" tool which allows u to do that.
The high demand and pay of the last few decades brought a lot of people into trying to be those few but it looks like the percentage of the "worthy" people remains as low as it was decades ago and move from Fortran to lowcode did nothing.
The issue is how the education system and teachers don't know the principles behind programming. They teach Algebra but they can't apply that knowledge to programming.
What low/no-code does is remove the setup and tooling barrier. I believe it's this barrier which scares most people away from programming. After all, even as an experienced software developer, I find some languages more intimidating because of the many tooling choices and setup options required before one can actually do something useful (front end development, anyone?).
Ruby on Rails did this for web development 20 years ago. It's way more complex now (partly because our expectations and desires are so much more complex), but when it was new it was essentially low-code compared to alternatives. And just with modern low-code systems, people who aren't good at thinking or structuring often create bad or unreliable things.
I'm sure more than a few of us have seen some of the monstrosities created by users with Excel. On the other hand, some non developers have created brilliant solutions in Excel. The same will be true of official no-code tools.
Where no-code can really benefit most, is by allowing some end users to attempt to solve their own problems. Chances are they won't end up with complete solutions, but they may end up with a clearer picture of what it is they want; and then they can go to professional developers and better communicate their needs. Maybe we'll end up throwing away less work as our solutions will better match the users' needs.
It indeed is: https://powerapps.microsoft.com/en-us/blog/power-fx-open-sou...
I'm surprised how infrequently this comes up, given the massive usage of Excel in the business world; low-code/no-code is always discussed as if it's something new. Non-programmers in corporate America have been building excel applications for decades. You'd be surprised and a little scared by how many business critical processes depend on an excel workbook stored on a sharepoint somewhere.
Interestingly enough, Excel in many ways is also a sort of functional programming for the masses. Excel functions are (mostly) pure. Columns are sort of immutable, and you tend to build applications as collections of smaller functions composed together as you might in Lisp.
Examples: ToolJet: https://github.com/ToolJet/ToolJet Obsei: https://github.com/obsei/obsei n8n: https://github.com/n8n-io/n8n
https://www.christies.com/lot/lot-a-sumerian-clay-cuneiform-...?
By the way,do you think anybody will pay that much for an 4000 year old Excel Sheet about let's say pork belly futures in that 4000 years?
I think that no/low code is the secret end goal for any B2B line of business product. You eventually want to be able to have sales engineers directly setting up your products for customers, with developers standing by to support or enhance the shared code pile. You never want to be in a situation where you need 1 developer and code pile per customer when you are trying to capture an entire market segment with hundreds or thousands of businesses.
Once you figure out all the likely paths through the jungle, you can expose configuration and scripting at the various decision points.
Our specific flavor of "low" code leverages SQL and projections of business state to allow for very precise tuning of certain logic. Being able to employ SQL to solve problems implies a very intimate understanding of the problem domain. You have to do battle with the business and iterate the model until you know 99% of it will never have to change. Anything less than this is walking across quicksand, as changes to schemas per already-configured customers quickly turns into a nightmare factory of regressions and otherworldly suffering.
Current favorite low-code tool: https://github.com/ToolJet/ToolJet/
Performance-wise sqlite probably wins, but Access had the added bonus of an extremely straight-forward UI
One such app had in all its tables a column called "useless". It turns out it was the primary key. The author didn't know what it was for and didn't figure out from its name that it was important. There were also foreign keys referring to the description columns, not the primary key column (which was useless, after all).
In one instance, I saw an IT manager being asked for support for an app he had never heard of. It was another attack of the coding accountant! I call it code and run.