That escape hatch is absolutely necessary for longevity though. It lets you keep your low-code environment simple because you can leave it and write real code when necessary, rather than forcing everything into an over-complicated and under-capable custom thing with no editor tooling.
All the components and modules that low code tools provide should be nothing more than an onboarding tutorial like the first few levels of Factorio, before letting the engineering team loose hand in hand with the users. It shouldn’t be an escape hatch, it should be the front door.
As such all these low code tools make the mistake of making it really difficult to bring the engineering team into the fold: modularization, logging, debugging, version control, and development tools are absolute garbage so instead of engineering providing a few sane company specific building blocks that they can tend and nurture, it inevitably turns into a shitshow because you can’t use a tool that ultimately depends on the IT department to fix the IT department!
The best “low-code” tools have already been around for over a decade: it’s the headless CMS and autogenerated admin pages ala Django and Wagtail. They’ve been focused on solving the content management problem for e-commerce and marketing, but IMO it’s the write path for other groups too. The engineers write the pages and blocks and components while defining an input/configuration schema for an automated tool that is usable by laymen. Up the level of abstraction to a well curated (by the engineers at the customer level) IFTTT layer and bam, you’ve 95% of use of low code without the 5% that inevitably ruins it.
It's also because knowing where the escape hatch and how to use it requires greater than average development skill and finesse and it isn't at all obvious when this is required.
The people who use these platforms aren't usually able to tell what kind of problem requires a developer and what kind of problem requires them doing just a bit more research. They're usually vaguely aware that the limit is out there somewhere but in the specific instances when they hit it they often don't know it's happened.
I've also seen some low code platforms get a little excitable about the idea of nearly or even fully reinventing the turing complete programming language to introduce more flexibility to their platform and make that their escape hatch. This is when things go really downhill.
Per end user rather than per developer means they're far too expensive to introduce as a general IT toolbox item, they need to be part of a major strategic project where the $5-30/month per staff user has a hope of being justified.
But that also often takes it outside the "IT Dept", which is often just "infrastructure and pc fleet" support, not development ( at least, that's my experience ). IT might do internal scripting and some service interface tooling, but business tooling and software is rarer, that's usually either dev teams or ERP teams. The ERP teams will already using ERP platform tooling, so that further narrows the market.
I don't have a good solution for this, but it's always been the hurdle I've tripped on working for medium size enterprises.
There would seem to be an opportunity for "open source platform, commercial training and support" here, but vendors seem to gravitate to per user head and cloud only for more immediate revenue and easier support., but again many enterprises still have huge internal only IT landscape's, because cloud is still expensive and the value often isn't seen in relatively static envs.
It's possible this niche has been filled now too, it's been a while since I looked...
Possibly they can be introduced on a "just those who need it" basis, but honestly that's just so bloody tiring for internal tools, not to mention demotivating as you can no longer build tools for "everyone or anyone", it's back to specific narrow business cases, not IT empowerment, but narrow business case also means your usually competing with cots tools or consultants.
The success of low code implementations often comes with a curse of investing man-years of development effort to build increasingly complex applications in proprietary low code languages executable in a closed ecosystem (and commercial terms) of a specific vendor.
I believe there is a place for enterprise app platforms which are a) open source, b) not based on proprietary languages, c) with low code capabilities, fueled with AI code generation, d) runnable anywhere without staying dependent on typically user-based commercial model.
Shameless plus: we are working on such a thing, and competing with traditional low code platforms is not easy, I could tell a few stories about what we have tried, what works and what not really, if you are interested. I would be also extremely thankful for any comments and hints you may have, see https://openkoda.com
That's the definition of vendor lock-in. Once the vendor has it's hooks in your organization, good luck removing it. Sometimes it's just the cost of doing business, but the more the hooks, the greater the chance that a vendor triples or quintuples the cost of their product that affects your organization's secret sauce.
I feel like the goal of low-code solutions is to get you over the barrel. Much in the same way AWS tries to get into your company's operating costs.
I create nocode plugins on a specific proprietary stalled platform, for a living, for a few years now, so I am definitely aware of the pitfalls in the area.
For me the problem is that the API to it got created in a nice format but then got abandoned, if they just listened over the years and added the changes we third party devs needed it would have been great.
Example from us using Azure Data Factory: You can add a step to call out to an API, which we did for a data flow that had a lot of calls. Performance was atrocious. Dug into it, and the API getting called was replying in 100ms or so, but ADF's "escape hatch" was adding 5-10 seconds of overhead to send the POST and parse the HTTP status code.
Microsoft Support said that's normal, expected behavior for the service.
In the end, we had to write an additional batching layer ourselves.
Whenever I've discussed this, the common theme is that business users continue to request features that would be easily achieved in the low-code platform being used. It's hard to blame them; that's been standard procedure for them for their entire career.
But if you're not strict about saying "no", you still end up writing all the same methods but now on top of that you have a GUI that's not providing any value. Or maybe worse, your developers end up maintaining all of the low-code stuff too when they could have just written the code, switching context pointlessly and (probably, depending on the platform) not using source control.
* Where was the design doc?
* Where were the alerts?
* Where was the code review?
* Why didn't you write an integration test?
* What do you mean it just rolled out to production instantly?
When we're considering options in advance of building something, it's a more time-efficient, less wasteful alternative to programming. But having built it, everyone acknowledges that what we have done is programming, and now they wonder why we've programmed so badly.
Maybe the standard IDEs, Git, code review, CI, metrics, and incremental deploy workflows were fine actually?
Without discipline, any programming environment can lead to failures.
It is true that there aren't any well-defined workflows for using an arrow-boxes environments but that does not mean that these environments don't support specific workflows.
I'd be really interested in knowing how often escape hatches like that are actually used. I'd guess it's less than a fraction of a percent, if ever.
And most apps use about 10 to 20 plugins.
If you just deleted a bunch of processes, or just reserved it to when it actually matters, you wouldn't need to pay a low code vendor to basically allow your team to do their job.
It eventually turned out there was a prioritisation problem rather than a development capacity problem.
One might think you need all of it right here right now - but in reality if you build 20% that is really really needed you get 80% or I could bet even 95% of actual work done needed for the company to improve productivity/performance etc.
I feel like you just explained how salespeople can scam decision-makers into thinking low-code solutions will do more than they can do, and in no way countered any of the arguments in the OP about it's dangers.
It's not just business knowledge, it allows the people who are most committed to project success to do the work.
I think that's the real pain point with IT departments in large organizations. They aren't feeling the pain that made you need the software in the first place.
Oh my... Many, many, maaaany reasons.
For example, your entire stack is built in a certain way and you don't want to introduce new dependencies.
What if your cicd requires your config and code is separate and that you build a code artefact, and let's say 3 config artefacts (dev, cert, prod), all these are then uploaded to a central repo and handed over to some proprietary security/code scanning thing every time you merge new code. Then let's say your deployment is done the same way, you have your "deployment config" artefacts for each environment, but an infrastructure team manages all the infrastructure-as-code artefacts that take your config.
I worked in a bunch of big companies each having their own version of such process.
In such an environment, creating an "example project" that contains all of the scaffolding required and just writing that sign on form is going to take waaaaay less time than even initial planning how to integrate the "no code" tool into our processes.
>In such an environment, creating an "example project" that contains all of the scaffolding required and just writing that sign on form is going to take waaaaay less time than even initial planning how to integrate the "no code" tool into our processes.
I've also seen the opposite. Someone in the org wants a simple site. Maybe a sign up form, or CMS/wiki for internal docs, etc. The dev team says "sure, that'll be 6 months". A large part of which is constrained capacity - the devs need to fit it in alongside a buch of other stuff. Another part is tech choice: the corporate stack uses e.g. React on the front end, calling web services written in Java, backed off to Postgres for storage (or whatever). The devs estimate for building the CMS/wiki/whatever from scratch - because it has to fit the tech stack.
At that point the (internal) customer screws up their face and utters all the familiar frustrations about "IT". Someone somewhere mentions to them that there's a way to sidestep it all, and do it yourself. In their position it's very hard not to see that alternative as attractive.
It's a hard problem. That same internal customer will similtaneously rail against the recharge in their budget for IT. It's a cost: a drag on their P&L. IT says they're under-resourced, and they could do it quicker with more people - but that would increase the P&L drag. Vicious circle.
Software is a sociotechnical endeavour yet we too often focus on the technical and ignore the social aspect. Yet "Low Code" and similar emanate primarily from the social side. Coming back to your post though, not exclusively. Development teams can be equally culpable when zeroing in on tech stacks that aren't a good fit for the problems at hand. Or, perhaps, stacks that are a good fit for the problems they were chosen to solve - but not so much when the new requirement comes along.
Of course, low code is no panacea either. Most non-technologists have no perception of the need for ongoing evolution, even if there's no new feature development. Patching/upgrading is a must. And new features always emerge - most after the original "citizen developer" has moved on / lost interest / whatever. So the whole shebang gets foisted on IT, who are expected to operate and maintain it. Usually with no tests, automated builds, documentation, ...
It's pernicious. At heart, though, it's primarily a social problem that needs a good underlying relationship between the customers/users and the developers. It's Conway's Law. Of course tech choice still matters. But no tech stack is going to magic away problems rooted in organisational friction.
I started my career as a Solutions Consultant. Our primary customers were small business units in large organizations that were frustrated with “IT” and looked externally to solve their problem. Low code is a variation on this strategy.
Our delivery time estimates always beat IT estimates and our costs were often less.
Maybe because we were seen as a competitor to IT, or maybe some manager was being sneaky our first interactions with IT was usually after the engagement contract was signed. (None of these projects had RFP/RFQs)
During the discussions with IT was when the hard parts of the engagement really happened. It was then we learned about the compliance requirements. Security, data integrity, availability, platform standards, ci/cd, pmi, etc…. These unknowns often dragged out our delivery times and skyrocketed our billable hours. Putting us equal to or behind internal IT.
In my experience at large organizations Compliance is more closely aligned with legal than IT but is often an a function of IT. The rules set forth by the legal teams are enforced through technical/process controls by IT. This makes IT look like the ‘problem’ went in fact they are just following mandates set forth be legal.
It’s often easy for a business unit to complain about IT preventing revenue growth and get an exception. If a business unit complained to upper management that legal wouldn’t let them do something I doubt exceptions would be granted as easily.
I’d suggest that compliance be its own department and review all external tools or vendors instead of IT. This would put external consultants or low-code solutions on par with internal IT. If would also shortened the feedback loop between those creating the rules and those it causes grief.
You can tell when your last warehouse is close to the customer by looking at a map. You can't tell when your tool is close to what the user needs with nearly the same accuracy. There are a ton of gotchas, and as part of the "last mile", it's now your responsibility.
You also are at the whim of the SaaS vendor to give you the help you need. If they can't do something you think it should, good luck making a hacked workaround to function as it must.
Imagine I bought a vacuum cleaner expecting it to clean all my floors, and never finding out what i bought was a pack of pocket tissues.
Pocket tissues are useful but not when im trying to clean my floor with them.
Did you have any positive experience on the after seeking low code?
Ironically it's the OT and logistics people who've figured this out, with low / no code solutions fit for purpose, which don't necessarily run in the cloud, which have full microservice / SQL integration... and baked in OT drivers, RFID and bar codes.
Kind of like “consultants” coming in with advice on how to improve the organization?
Low code is very easy to sell. All you have to do is make a boogie man out of the IT department, and play on existing frustrations. Then play a demo where a sign up form is made in ten minutes and say your IT department would have taken 3 months. You just make sure to walk the happy path during the demo and don’t stress the tool.
Many things could be low code. Why do you need a developer for a sign up form if you are just making an API call in the end? Wiring up a form shouldn’t take html, js, and a serverside language.
On the flip side, don’t put your core business logic in low code. Low code builders assume anything complex will be offloaded to a specialized system. The best ones provide escape hatches by calling remote APIs or calling a code module.
Low code gets sold to smaller customers because it’s touted as a developer replacement. But really it’s most powerful in larger enterprises where individual teams may have technical people who have business knowledge but not much much IT power. It’s easy to get them to configure something in a SaaS they already use, than get a custom solution from IT. Also low code often comes with guardrails and permission sets tied to existing users.
I see low code as a tech equivalent of the last mile problem in logistics. It addresses a large number of concerns with simple tools, but doesn’t scale well and needs to work in tandem with a stronger central system. End to end low code is a trap, but low code at the fringes is a multiplier.