The biggest thing I learned, the secret truth, is that "low-code" is intended to be a force multiplier for "real programmers". Low-code dev shops look exactly like every "real" shop I've seen: source control, sprints, Jira, "omg feature creep" meetings, insane stakeholders, the works.
"low-code" developers are "real" software developers. They are developing software that is intended to be used at scale by real people to perform a business task that produces value. This stuff is deployed at "real" companies. I'd wager any sum you're using products and services every day that are connected to one of these platforms. (I'm talking, are you an American who goes to the doctor, goes to any national retail chain, buys products and services from large online vendors, etc)
It's a complicated and weird industry but it's been incredibly eye-opening.
Most vertical market solutions were started by advanced end users trying to solve their own day-to-day problems. Chances are they couldn't afford to hire a team of developers to build them a custom solution, so they cobbled one together themselves. Other people in their field see what they're doing, get excited, and a lightbulb goes off - "I can make a business out of this!".
Eventually it gets to the point where those solutions need to start following the rigors of a proper dev shop, but in the early days, it's more often than not the "low code" dev that you're talking about.
Funny thing with Pega is once you break out of the normal BPM-style flow, you'll write almost as much code as an all-code platform, just cookie-cuttered into form fields.
There is a need for wide variety of programming tools, ranging from very low-level to very high-level. Any of them is a trade-off in terms of flexibility / cost of development. Picking the right tool for the right job will always be a problem to solve, but having more tools to choose from would never hurt.
Someone who assembles an Ikea cabinet isn't necessarily a master furniture maker (altough they could be!). If all you need is a cheap, cookie cutter coffee table it'll not only do, but it'll be the fastest and cheapest option. However, if you're looking for a bespoke cabinet with dovetails, you're going to need a furniture maker.
I tend to agree with it but there is a bit of idealization here. How to code does matter. It helps to not care about RAM barriers, CPU registers, memory pointers, etc. The span of human attention is only so much broad. Constantly dealing with low-level details obstructs seeing a bigger picture. Assembly coders don't think much in terms of type classes or lazy evaluation.
bigato, on the other hand, is pointing out that the brains are relative, i.e. regardless of the programming language, you still need a programmer's brain using it to be successful.
My experience has been that this is a very challenging problem. Business leaders consistently apply pressure for faster results (rightly so!) which means that technology leaders will also be under pressure to deliver faster results.
Tools at the highest level of abstraction (like the various "declarative programming" app builders) trade away power and flexibility in return for simplicity. The sales teams that sell these tools then inevitably highlight the speed and gloss over the trade off that's being made. The message that buyers (business and tech execs) hear is that a tool can solve problems faster.
That is often true when the tool is being applied to a problem for which it's suited and can be disastrously incorrect when it's applied to a problem it's not suited to.
My experience is that the promise of "faster" often drowns out the voices warning that a tool is being applied to the wrong kind of problem.
If I can do 95% of my work using the super simple UI, and then for that last 5%, I can go in and hack my way with some code, I'm much happier than having to write 100% of the code with code.
Of course, if that last 5% is impossible to achieve at all, then yes, you're definitely not going to be happy and that 95% will have been a total waste.
You're right, but you're also looking at it from the lens of a programmer.
From a user's perspective, they have a problem to solve, and they just want a tool that will help them. From their perspective, they are not thinking about it like a programming problem. Even if they have to write a little bit of script/code, they don't necessarily perceive what they're doing as programming.
That's why Filemaker Pro, Hypercard, Excel, Notes, etc. developed huge popularity among "advanced end users".
And at that point, the user is stuck. Customer service recommends posting a feature request in the product forums and all the user can do is wait... and hope something gets implemented that solves their problem, or find a new tool.
But with programming, it's possible to execute scripts, make system calls, write to files, and initiate network connections to talk to APIs and invoke other 'tools' to continue the task at hand. The tool is now a shape-shifting collection of code that can take on many challenges, limited only by the creativity of the developer. You can't do that with a WYSIWYG, it would be too complex to allow all these functions, so the next best thing is allowing plugins, at which point the tool now requires programming knowledge anyway.
Once again, this depends on the lens you view it with.
With any solution that does a good job, it will eventually grow. Sometimes it outgrows what it was already built upon.
I see this is as a good problem to have, because it's a validation that the problem was real, and that the solution has value. You can also now justify putting some resources against it.
If your starting point is "this problem needs to be solved with programming" and A) you don't have that skill, B) you don't have the money to hire a person to do it, C) your organization isn't willing to give you a skilled internal resource to build it, what are your options?
You can either do nothing and live with the problem indefinitely, or you can try to do something that doesn't involve "real programming" to make your life a little easier.
So maybe now with that proof that a small investment paid off, it is time to take it to the next level and make a larger investment to do it better with professional grade tools this time.
Yes, you have to start over, but if the other alternative was never being able to get to that point in the first place, it's still better overall.
> And at that point, the user is stuck. Customer service recommends posting a feature request in the product forums and all the user can do is wait... and hope something gets implemented that solves their problem, or find a new tool.
Is this not the problem with any programming language? It's turing-complete, yet you find something you can't do (I mean, brainfuck is turing-complete, but try implementing a closure in it), you complain to the maintainers, they say it doesn't fit the design criteria. Sure, you might be more likely to fit those limits earlier in a visual code design tool, but that's not a fundamental design limitation, just an implementation one.
There is a lot of complexity that is completely unrelated to the core logic of a solution to a particular problem.
They usually have their own jargon/terminology and concepts to learn.
So they just move the goal posts...
But I think it depends on what sorts of problems and solutions we're talking about. I don't believe for a second that all types of software can be created with this sort of end-user oriented wysiwyg + expressions tool.
I’ve seen lots of demos (and bought lots) of reporting or automation tools intended for the “CEO” to make their own ad how reports only to have that mean that consultants are hired or someone else do it.
At the end of the day, the hard part for many people is the idea of variables and abstraction and interfaces and looping and operators. Making a button vs a keyword to do this is maybe easier, but it doesn’t really Bridge very well to non-programmers.
The closest I’ve seen is Excel with people who will not try R or Python but can write lots of stuff in Excel functions and pivots and maybe macros.
There have always been power user types in small and large organisations who are not developers but can create simple solutions, mostly using point and click with some expressions, macros or SQL added in. The ones I have personally met have used dBase, Excel or Access (one of them a non-tech CEO).
Of course they had to learn how to do it. But it didn't take them years to learn nor is keeping the skills fresh a full-time commitment.
I think this is largely a disagreement over definitions. Can something that doesn't involve writing loops and mutating variables be called "building business apps"? I would say yes, but I understand how reasonable people could disagree on that.
It will certainly not replace a lot of complex applications, but if you just want a quick "order a mouse at the internal servicedesk" app then what's the harm?
In my experience that never happens, though, and you either have an incredibly painful process trying to work around the limitations of the app maker, or you end up with a rewrite anyway.
That was true 30 years ago, when VB was popular, too. Heck, that was true 50 years ago, when CICS was popular. "Forms to send data to a backend" is deceptively complex.