Low-Code and the Democratization of Programming
oreilly.com
oreilly.com
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.
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.
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.
- 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 processes on closed source tooling
[1] https://github.com/Budibase/budibase
By your logic, shouldn’t you also disclose that you are a marketer for a for-profit no-code app platform?
Disclaimer: I am creator of Obsei
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...
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.
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.
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.
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.
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.
Since this is likely not going to change, these no-code tools expand the number of workers who can do stuff. But it clearly isn't as good as coding and never will be
The articles then shows that it is far from a "past decade" thing.
Low-code, no-code, RAD, or whatever you want to call it has always been a thing. Code is an obscure thing to the uninitiated, and it costs a lot of money to hire the initiated. So of course people want to make it more accessible. Today is nothing new, if anything, it tends to go the other way: people are getting more comfortable with code.
And the article explains it very well, in fact, it is one of the best overview I've seen. It takes about Excel, the most successful "low-code" platform, UML, which is mostly a failure, and modern takes like Copilot which offer guidance but do not try to hide the code.
The conclusion however seems to be "I don't know", told in a particularly convoluted way in entire chapters. I think the article would have been better if it didn't try to predict the future.
Examples: ToolJet: https://github.com/ToolJet/ToolJet Obsei: https://github.com/obsei/obsei n8n: https://github.com/n8n-io/n8n
This, so much this!
The amount of wilfull low-code ignorance of standard, 20-year+ old best practices for producing reliable software is mind-boggling.
Integrate with standard version control. Have a textual representation of your source. Integrate with standard CI/CD.
No, you are not a special snowflake. And no, no one wants to have to use your cloud SaaS build tools vs something they can own, integrate, and run themselves.
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?
Like isn't a turing complete language proven to be the highest level one can go to be able to do anything required with code?
Everything past that reduces the amount of code but also reduces the number of things the code can do and at some point in the code reduction, it's just a declarative language?
Its all shades of gray between imperative/functionsl and declarative.
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.
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.
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.
Current favorite low-code tool: https://github.com/ToolJet/ToolJet/
Who signed it? I cannot find 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.
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.