I am on the other side of low code, building the builders for the most part, here is what I see.
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.
Low code with an escape hatch is quite nice, because yeah - many things can and probably should be low-code. It's a big productivity and standardization enhancer.
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.
Low-code tools have a market fit problem because of that escape hatch. The players keep trying to sell it as a solution to IT deficiencies but it should be sold as an IT empowerment tool. It really doesn't matter how good your last mile delivery is if the shipping container with the product isn’t where it’s supposed to be to begin with.
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.
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
Having escape hatches is critical, but they should also be well built, or it can cause just as much headache.
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.
Agreed, with the caveat that you also need a policy/culture that the escape hatch should be avoided whenever possible and the low-code work should not be done by developers.
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.
This is still usually tech solving an organization problem. Launching normal apps gets gated under security, product, or technical reviews but the low code tool becomes a backdoor to all that.
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.
We tried low code (citizen development) as a solution to the "IT dept sucks" problem. It worked pretty well at the start but eventually became a data governance nightmare and as soon as we needed to restructure the business we ended up with ownerless applications and datastores all over the place.
It eventually turned out there was a prioritisation problem rather than a development capacity problem.
> 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.
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.
> 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 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.
>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?
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.
this is simultaneously a valid reason not to use low code tools - and why they find favour in many organisations.
>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 like your analogy to the last mile problem in logistics. I would argue in that case people know they are using bespoke, last mile only, systems because there is no other option. Low code vendors promise much more than that, end to end capabilities.
I adopted an official personal policy of not working on any data project referred to as "last mile". It's a big sign it's going to be under-resourced and under-appreciated. The last mile is brutal. And that's in the physical world!
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.
I'm curious, do you ever mention anything along the lines of "don't put your core business logic or mission critical stuff in this" ? That could backfire, but it needs to be said.
So from a certain perspective, the positive niche / need it would fill is enabling the local power users who might also do complex Excel queries, or have their own MS Access, etc?
Similar, low code is a bit broader and is usually associated with a business process like taking in a lead, providing a quote, or approving a transaction. Excel can do the calculations for these things but still requires a lot of human interaction. Low code can do a bit more like generating a form, evaluating branching logic, or handling an async process over time.
> I see low code as a tech equivalent of the last mile problem in logistics.
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.
Seems like the generators and gem ecosystem in Rails already solved these problems. I can easily build a devise login in less than 10 minutes. Low code in Rails is almost instantaneous and you get tests automatically too.
As an SRE that occasionally encounters low-code things I'm also pretty skeptical..
* there is like no source control, or if there is the source controlled thing is an unreadable artifact which generally doesn't belong in source control.
* the workflows are poorly if at all documented.
* they still require a lot of custom code but that code isn't as reusable, tested or testable
* they often require a proprietary runtime, worse this may only run on windows
* they are difficult/impossible to instrument and so are difficult or impossible to monitor. Or if they do have monitoring it is going to work differently than the rest of your stack - likely using email based alerting which isn't ideal.
* the work is still 100% done by engineers either way, I've never seen a low code or DSL be picked up by non-engineers. (I am also skeptical towards DSLs)
The only tool that was semi-reasonable here was Looker which isn't exactly marketed as low code but at least in the version of the product I used did integrate with source control. Though generally the people writing lookml were still engineers.
I'm much more a fan of composable platforms that compress complexity but still make it possible to delve, customize and extend when necessary.
> * the workflows are poorly if at all documented.
Ideally it would be easier to understand if there's less code involved. Things should be more declarative, or the low-code solutions would generate good descriptions for what is actually happening.
> * the work is still 100% done by engineers either way, I've never seen a low code or DSL be picked up by non-engineers. (I am also skeptical towards DSLs)
Or worse: "Why does this connection to this server fail with SSL Certifcate Invalid? Oh, nm, we'll just uncheck the SSL validation box."
But really you are missing a key piece of the puzzle, it matters less what is happening and more why. Sure a low code tool could churn out a textual description to say if the value of some variable is < some threshold branch to X else branch to Y, but thats generally easy to figure out, why is that threshold important, that’s a question that requires understanding the intention of the user of engineer who set it up, that’s not something you can just puke out of an auto-doc tool.
I would go so far as to say the inability to capture intention is one of the sharpest edges for low-code tools, it makes the solutions built on then extremely brittle and creates silos of knowledge.
Expanding on that further this is why most auto generated documentation is worth the effort put into it.
It should be easier to understand but lowcode designers seem to like making you jump between 30 different screens instead of having it all in one place. Unspooling a lowcode implementation has got to be one of my least favorite activities.
I think Retool is the best I've seen. They have source control, great documentation, reusable custom code, can tie in external apis for monitoring.
I'm someone that has a little less than junior dev experience (I can hack together a website), but nowhere near the ability to work on production code, yet I was able to be proficient with Retool. The only downside is the cost.
> here is like no source control, or if there is the source controlled thing is an unreadable artifact which generally doesn't belong in source control
I think this is an artifact of "source code is text" that our current tools assume (and is invalid IMO).
i think the concept of "source code as AST" or something like that is basically a fine one, but the devil is in the details. your "true source" must continue to support (just off the top of my head):
- precise "decompilation" to readable, idiomatic text
- comments
- line numbers or some semantic equivalent
You do understand that source code as text in current form is most efficient way to do it?
There is no more efficient way unless you go to down to writing assembly or go down to writing 1 and 0.
Everything you build up as low code has to create much more data which takes obviously much more space than high level languages we use today and if you want to do change control - any other data structure will take even more space. Then all of it will be obviously slower because more data is not just a bit more data but at least order or two orders of magnitude more.
LLMs are great at compression but compression with them is not lossless so even if we write behavior to be interpreted by LLM to be executed it might turning out differently each time you run it.
That last one is not a tradeoff we can deal in I would guess 95% of applications. People expect 2+2=4 from applications but they want to say „computer add two numbers that add up to 4” and they don’t really want to to crash because pi+x=4 and LLM went hanging because it is now calculating PI and then it will move to finding X.
So this is why it will never work other way than „source code is text”.
SQL is a DSL for data manipulation and I like it more than non-DSL code (ORM frameworks). Puppet language is a DSL and and I prefer it to Ansible (and alike) Yaml files (yaml is OK for small projects but hard and tedious to maintain for large ones).
"Low code" means a low surface area of code you can directly interface with, but there's plenty of code shoved out of sight and out of reach. Total amount of code is probably actually quite a bit larger, actually, given all the code needed to create the abstraction layers to give the appearance of low code.
Layers of abstraction are powerful when they're tight and well-suited to their purpose (I'm happy to never think about memory allocation -- thank you garbage collected languages!), but when leaky or ill-suited can be very frustrating and make things harder or impossible.
It's hard -- probably impossible actually -- to build a "general purpose" abstraction layer that will work for specific purposes, but that's essentially the pitch of low code -- we don't know your specific use case, but we have a tool that will abstract away all the code previously tailored to that use case.
Now, in fairness, there's a lot of code that has too much accidental complexity in it. A good abstraction layer strips away that accidental complexity and leaves only the essential complexity that's specific to your domain and use case. But that's hard to achieve -- it takes skill and experience (and not just general experience, but specific to your domain experience) to achieve. Most companies don't have that available to them, and don't want to pay rates to build teams that do have that skill set and experience. Low code holds out the promise of being a short cut to that, but clearly if your own dev team can't manage it, the odds of a generic platform doing it for you is slim to none.
All I know is that I was quoted $50K from a Ukraine team to build an MVP, as long as I could provide detailed specs down to every function. I hired an intern who used bubble/airtable to build our product in two months and had ten paying customers in 6 months. After almost two years have yet to find a reason to move to a traditional stack. We have had 6 hours of down time in those two years thanks to bubble issues. I can live with that.
Not a fair comparison. One you were asking for fixed price contract the other you are paying a salary. The salaried person is more likely to be able to be agile and not need requirements (if you said to the intern $20k once I am happy with the job they’d say “define happy” and you are back to requirements!)
As for code vs. no code. If (big if!) bubble can do what you need it can be a cheaper route to launch an MVP.
Where I see no/low code fall apart is when complex input data validation is required. However, I can also see that this might be our old practices getting in the way of innovative forward thinking.
Maybe you've found a way, since you are starting from scratch :)
FWIW I run the IT dept for a mid-level talent agency. I moved us off an old system and into Airtable specifically because it’s flexible enough on every front. The killer feature for me is the concept of “views”, which means we can have all the data available at all times, but only surface the data that a particular user needs for them. In a company full of less than technical people, this has been an absolute godsend.
And when we continue to grow, there are ways off of Airtable since it’s all just CSV underneath.
I'm 100% against enterprise-level low code stuff. If you're big enough to afford that junk you're big enough to afford proper development teams with proper planning and organization.
In general I see little value in any large system intending to reduce the amount of code or the needed skills of the developer. Code is not costing you money. Good developers are not costing you money. You know what costs money? Bad developers making bad decisions using bad tools, necessitating years if not decades of paying armies of lesser-skilled developers to maintain the mess, slowing overall progress to a glacial pace.
Largely agree... and to top it off, the pricing models mostly work against ever having a successful deployment of one. Either you price per end user, and optimize against building anything that is widely adopted, or you pay per developer, in which case you need to figure out up front who are the people with unmet needs who also happen to have the knowledge, skills, inclination, and time to build their own solution. (and this is enterprise pricing, so you need to know up front for at least a year how many of these you'll have, or you'll end up in a contract renegotiation or paying expensive overage fees.)
I think problem is that not every company can hire and retain proper development teams.
That is some wild goose chase that also causes buildup of „agile” smoke and mirrors market and the same with „low code” smoke and mirrors market.
I was quite skeptical about talent shortage in IT but the loner I work on the space the more I see and understand. As there are real issues with talent and agile or low code are ways of coping with the problem.
Most enterprise software is terrible, it's the lowest quality software you will come across. Paying more for good developers won't fix that because the problems all emanate from the enterprise itself.
I’m assuming you’re taking a rhetorical liberty here and really mean “net money”, but then what if you can get a similar end product for lower price? That’s higher net money.
What counts for "similar end product" typically ignores all future needs of the business. One project gets accomplished and everyone gets a pat on the back and a bonus. Then as the years go by the accomplishments become more and more mundane. For example, upgrading the enterprise software to a newer version suddenly counts as progress and everyone once again gets a pat on the back. Eventually everyone wonders why the IT expense is so huge and why the company's software seems to be treading water. So someone bites on another sales pitch and years are spent transitioning to some awful alternative enterprise turd, and the cycle continues until bankruptcy or acquisition.
A lot of useful MS Access and Excel apps written by non-programmers beg to differ. Sure they have their problems, what doesn't? But these low-code tools allow smart, but less technical, people to get a lot done without getting in line to beg time from a bunch of grousing devs stack-hopping their way to their next job. Use a commercial vendor and you might even get documentation and support. 80% solutions usually do more than was needed if the requirements had been thought through carefully. Most business apps are tables, filters, queries, detail views, and workflow. So what if a product with 5 users in a department is trash? Works well enough most of the time.
Startup can't afford more than one developer? Product owner can hack the thing until you get customers, funding, or go out of business. Oh, and that bus factor goes up to boot. No more pager duty.
Code things that are core to your business and plan for the TCO. Use low-code for internal business apps and let your smart intern or low-code consultant make and own it.
I've seen the opposite. Business hires new CTO who has no knowledge of existing stack and why it is breaking but sells the top brass on a low code replacement because of how quickly he can build with it. Spends a year building the replacement, forces a hard switch and fireworks ensue.
I've never seen a local hardware store shed kit that wasn't complete garbage for the price.
Building a simple shed isn't hard, if you can handle assembling the kit you can buy and cut the basic materials yourself. The trickier parts like getting it watertight or installing doors and windows have to be done either way, all the kit gets you is a bundle of inferior materials and a bit of time savings cutting studs.
I was involved with a project to decomission a low code on premise platform (Sharepoint 2013). What we found was there was a lot of user enthusiasm to create stuff but when the platform was end of life and had to be decomissioned the users enthusiasm melted away.
The "IT" dept had to spend a fortune re-validating the user requirements for the various applications, documenting and then converting them into a new platform. Obviously a lot of feature creep and previously accepted bugs (no longer accepted now that responsibility was no longer theirs).
A lot of the applications were frankenstein efforts from people over the years - lots of dead code no longer used, no docs etc. As others have mentioned people create mission critical stuff for their project or team, and then leave or be away on extended leave and it breaks etc.
Readit News
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.
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.
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
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.
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.
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.
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.
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.
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.
Deleted Comment
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?
* there is like no source control, or if there is the source controlled thing is an unreadable artifact which generally doesn't belong in source control.
* the workflows are poorly if at all documented.
* they still require a lot of custom code but that code isn't as reusable, tested or testable * they often require a proprietary runtime, worse this may only run on windows
* they are difficult/impossible to instrument and so are difficult or impossible to monitor. Or if they do have monitoring it is going to work differently than the rest of your stack - likely using email based alerting which isn't ideal.
* the work is still 100% done by engineers either way, I've never seen a low code or DSL be picked up by non-engineers. (I am also skeptical towards DSLs)
The only tool that was semi-reasonable here was Looker which isn't exactly marketed as low code but at least in the version of the product I used did integrate with source control. Though generally the people writing lookml were still engineers.
I'm much more a fan of composable platforms that compress complexity but still make it possible to delve, customize and extend when necessary.
Ideally it would be easier to understand if there's less code involved. Things should be more declarative, or the low-code solutions would generate good descriptions for what is actually happening.
> * the work is still 100% done by engineers either way, I've never seen a low code or DSL be picked up by non-engineers. (I am also skeptical towards DSLs)
Or worse: "Why does this connection to this server fail with SSL Certifcate Invalid? Oh, nm, we'll just uncheck the SSL validation box."
But really you are missing a key piece of the puzzle, it matters less what is happening and more why. Sure a low code tool could churn out a textual description to say if the value of some variable is < some threshold branch to X else branch to Y, but thats generally easy to figure out, why is that threshold important, that’s a question that requires understanding the intention of the user of engineer who set it up, that’s not something you can just puke out of an auto-doc tool.
I would go so far as to say the inability to capture intention is one of the sharpest edges for low-code tools, it makes the solutions built on then extremely brittle and creates silos of knowledge.
Expanding on that further this is why most auto generated documentation is worth the effort put into it.
I'm someone that has a little less than junior dev experience (I can hack together a website), but nowhere near the ability to work on production code, yet I was able to be proficient with Retool. The only downside is the cost.
I think this is an artifact of "source code is text" that our current tools assume (and is invalid IMO).
Otherwise I agree
- precise "decompilation" to readable, idiomatic text - comments - line numbers or some semantic equivalent
There is no more efficient way unless you go to down to writing assembly or go down to writing 1 and 0.
Everything you build up as low code has to create much more data which takes obviously much more space than high level languages we use today and if you want to do change control - any other data structure will take even more space. Then all of it will be obviously slower because more data is not just a bit more data but at least order or two orders of magnitude more.
LLMs are great at compression but compression with them is not lossless so even if we write behavior to be interpreted by LLM to be executed it might turning out differently each time you run it.
That last one is not a tradeoff we can deal in I would guess 95% of applications. People expect 2+2=4 from applications but they want to say „computer add two numbers that add up to 4” and they don’t really want to to crash because pi+x=4 and LLM went hanging because it is now calculating PI and then it will move to finding X.
So this is why it will never work other way than „source code is text”.
What you would suggest instead of DSL?
SQL is a DSL for data manipulation and I like it more than non-DSL code (ORM frameworks). Puppet language is a DSL and and I prefer it to Ansible (and alike) Yaml files (yaml is OK for small projects but hard and tedious to maintain for large ones).
Layers of abstraction are powerful when they're tight and well-suited to their purpose (I'm happy to never think about memory allocation -- thank you garbage collected languages!), but when leaky or ill-suited can be very frustrating and make things harder or impossible.
It's hard -- probably impossible actually -- to build a "general purpose" abstraction layer that will work for specific purposes, but that's essentially the pitch of low code -- we don't know your specific use case, but we have a tool that will abstract away all the code previously tailored to that use case.
Now, in fairness, there's a lot of code that has too much accidental complexity in it. A good abstraction layer strips away that accidental complexity and leaves only the essential complexity that's specific to your domain and use case. But that's hard to achieve -- it takes skill and experience (and not just general experience, but specific to your domain experience) to achieve. Most companies don't have that available to them, and don't want to pay rates to build teams that do have that skill set and experience. Low code holds out the promise of being a short cut to that, but clearly if your own dev team can't manage it, the odds of a generic platform doing it for you is slim to none.
> It's hard to build a "general purpose" abstraction layer that will work for specific purposes
I would phrase this a little differently. It’s impossible to make good tradeoffs without an understanding of the specific use case.
“Lossless abstractions” are possible, just rare as they usually come from understanding essential mathematical properties.
As for code vs. no code. If (big if!) bubble can do what you need it can be a cheaper route to launch an MVP.
Where I see no/low code fall apart is when complex input data validation is required. However, I can also see that this might be our old practices getting in the way of innovative forward thinking.
Maybe you've found a way, since you are starting from scratch :)
And when we continue to grow, there are ways off of Airtable since it’s all just CSV underneath.
Deleted Comment
In general I see little value in any large system intending to reduce the amount of code or the needed skills of the developer. Code is not costing you money. Good developers are not costing you money. You know what costs money? Bad developers making bad decisions using bad tools, necessitating years if not decades of paying armies of lesser-skilled developers to maintain the mess, slowing overall progress to a glacial pace.
That is some wild goose chase that also causes buildup of „agile” smoke and mirrors market and the same with „low code” smoke and mirrors market.
I was quite skeptical about talent shortage in IT but the loner I work on the space the more I see and understand. As there are real issues with talent and agile or low code are ways of coping with the problem.
I’m assuming you’re taking a rhetorical liberty here and really mean “net money”, but then what if you can get a similar end product for lower price? That’s higher net money.
Startup can't afford more than one developer? Product owner can hack the thing until you get customers, funding, or go out of business. Oh, and that bus factor goes up to boot. No more pager duty.
Code things that are core to your business and plan for the TCO. Use low-code for internal business apps and let your smart intern or low-code consultant make and own it.
If you want to build a shed, go to your local hardware store and buy a kit set.
If you want to build a skyscraper, get an architect, some engineers and a competent building company.
Building a simple shed isn't hard, if you can handle assembling the kit you can buy and cut the basic materials yourself. The trickier parts like getting it watertight or installing doors and windows have to be done either way, all the kit gets you is a bundle of inferior materials and a bit of time savings cutting studs.
The "IT" dept had to spend a fortune re-validating the user requirements for the various applications, documenting and then converting them into a new platform. Obviously a lot of feature creep and previously accepted bugs (no longer accepted now that responsibility was no longer theirs).
A lot of the applications were frankenstein efforts from people over the years - lots of dead code no longer used, no docs etc. As others have mentioned people create mission critical stuff for their project or team, and then leave or be away on extended leave and it breaks etc.