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.
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."
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).
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 :)
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.
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 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.
Can I check a "low-code" implementation into version control, using standard free tooling? Can I, when something inevitably goes wrong, do a `git log` equivalent to spot the source of the problem? Can I then roll back to a specific commit, using off-the-shelf free tooling?
I find that generally the answer is most often "no," which is kinda a nail in the coffin for serious usage of "low-code."
You do realise that there were ways to debug things before GIT came along? Indeed before source control came along?
What im saying is that you should be wary of ignoring things that don't fit into your current work-flow, because sometimes that "critical" thing in your workload is less critical than you think.
I build and maintain stuff in Power Apps, when it makes sense. You can export your solution as a ZIP file containing human readable-ish XML/JSON definitions of everything (GUI forms, tables, processes, etc.).
This is the version control/CD process I designed:
- We have a normal Git repository, hosted in Azure DevOps cloud
- Developers work in the "unmanaged" cloud-hosted Development environment
- When ready to move a set of changes forwards, the developer branches the repo, and runs a PowerShell script to export the solution from the Development environment to a local ZIP file, which is then automatically unzipped. The only other thing I do is reset the version number to 0.0.0 within the `solution.xml` file, because I'm pedantic and the code isn't necessarily a deployable build yet - it could be an intermediate piece of work.
- Developer reviews the changes, commits with a message that links to work items in Azure DevOps, and creates a pull request -- all standard stuff
- On the Azure DevOps side, once a PR is merged, we build a managed ZIP -- which is really just the same code, with a flag set and re-zipped up with a version number that matches the DevOps build number (in the Power Apps world, "managed" package deployments can't be customized on UAT/Production without explicit configuration allowing it)
- We then use all the normal Azure DevOps YAML pipeline stuff to move this between UAT, Staging and Production with user approvals etc. The Azure AD and Power Apps integration makes this very pleasant - everything is very easy to secure, and you don't need to pass secrets around.
- You can rollback to a specific commit using normal Git tooling or just redeploy a past build if there is one available.
That all being said, most people don't do the above. I should probably sell a training course, because it took quite some time to put all the pieces together. The bigger problems are planning ahead for changes without breaking stuff that is already live, because you generally only use 1 development environment for an entire team.
There's lots of good general criticism about Low Code tools, and certainly lots of it is valid depending on the tool and the context.
Of course, just like say the SQL or NoSQL debate there are contexts where one wins, and another fails.
I did have to smile at this though;
>> "Now, rather than being to recruit from a large pool of ubiquitous, open-source language developers, the company has to find maintainers who are very specialized in this tool."
From a company point of view this is correct. You cant just discard programmers and get a cheap, out-sourced one as a replacement.
On the other hand, as a somewhat older programmer, I like the idea that I get more valuable with age not less. I like that I can't be replaced by some ubiquitous open source freelancer who works for $20 an hour.
For the record I've been working with a low-code tool for 30 years (since long before "low code" was even a description) and I've seen thousands of one-man companies be successful developing programs where the owners actual programming skills are, well, in most cases, somewhat poor.
Turns out, making something useful has more to do with fixing pain, and less to do either writing code.
And yes, all the points listed in the article, and these comments, are true. And ironically almost none of it actually matters.
There are a million reasons it -shouldn't- work and yet, somehow, at least in my world it does.
I think this is the key a lot are missing. It’s about solving the problem, not necessarily doing so in a way that’s preferred or familiar to you. Low code has prod/cons but it has a place in the industry that many developers seem to be too arrogant to acknowledge.
Eh the thing is that Worse is Better and "Actually available to people in Operations without having to beg for permission" is the best of all.
VBA (Visual Basic available in Excel and Outlook) had a lot of the same issues as low code, as in no version control, no workflow for review or continuous testing and integration, no ability to do lots of custom things, that did not stop it from running the planet. I mean if you did the VBA version of Thanos-snapping half of all VBA code out of existence, most of society would cease to function within a week.
Power Automate is going to replace VBA soon because VBA can no longer talk to web pages thanks to the end of Internet Explorer and lack of VBA updates. And like VBA, Power Automate has all of the same problems - no concept of code review, version control, history, logging, actually its worse.
VBA at least let you have custom Types and Classes but in Power Automate everything, literally everything, is a global variable. Power Automate is lower code than VBA. But I think it will be used even more.
Because it is already installed on every almost every office computer in the world. This is the only tool ordinary Ops people will have available to them to automate stuff, so that is what will get used.
I have been since the first people at my previous employer told me it would replace all the programmers.
Then I found out the developers assigned to working on the low/no code parts had a component where they could write Java inside their low code process. There were hundreds of lines of code in each business process in the low code parts. They were writing giant methods in their process wired up by the true low/no code part.
To make matters worse the tool did not support unit testing of the custom code.
It ended up being like dozer mapping entity to entity and then passed along to custom code. All wrapped in some crummy UI. It produced a jar file which would be deployed anyways.
Maybe the tools are better now. We had some Tibco product at the time.
This to me is true for low code tools that are aimed at non-developers. “You can write software without software developers!” But low code tools made specifically to help developers’ workflows can be great. Maybe would be good for OP to clarify type of low code tools
It is so so so close to being a silver bullet tool for quick front end crud that can use your AD to authenticate.
Instead though, it’s got the most absurd pricing model that even their own reps don’t understand and is missing critical or basic features, requiring strange workarounds (fucking UTC dates vs what’s actually in the DB).
They USED to have no way to reuse code as well but they fixed that.
I feel like the issue is they’re still too married to basically low/no code environments.
Having a “I’m going to need to do a custom script in whatever” option would smooth out the edges so much
Power Automate is great, but PowerApps is just a mess where every click in the dev interface takes like 5 seconds. On paper it looks so good, but in practice it is so painful to get that on paper performance and functionality.
I tried to use PowerApps 3-4 years ago and it was a hot pile of garbage. Slow, impossible to use, underwhelming configuration options, no version control...a developer's nightmare
We started out with webflow for our landing page. Problem with low code or any abstractions in general is that it becomes leaky the moment you want to do complex stuff. The reason webflow worked for us initially was we did not have to bother with hosting, CMS etc. It because very restrictive at one point. Only couple of people know how to make certain changes.
Eventually we moved to nextjs and vercel. We are faster with iterating on our landing page as well as any engineer can be pulled into the implementation.
All lowcode platforms are great in basic usecases but fails when the usecases because complex.
Where I use low code is in essentially expert systems, where I need to encode the expertise of some SME. For instance, a lot of places have regulatory compliance burdens. The detailed rules for compliance changes by jurisdiction constantly. Most enterprises setup some sort of requirements to engineer pipeline that everyone’s bitterly unhappy with. It is never fully compliant, has tons of errors, the engineers resent their jobs, and the SMEs resent the engineers. Instead by instrumenting the system with a low code surface area with a policy management system overlaying it you get an excellent platform engineers like to develop, SMEs can author and manage their policies directly, and you capture a rigorous workflow which auditors and regulators really dig. This doesn’t make the engineer less important, in fact they’re much more important to ensure the policies are expressive enough and touch enough business data to ensure the policies are complete. They’re just not playing regulatory policy telephone games in code.
There's definitely something to this. What comes to mind is things like tax compliance. It's a moving target, software devs almost universally do not want that domain knowledge and accountants/lawyers almost universally do not want to represent that knowledge in C++.
I'd find this article more useful if it named names - I still only have a loose idea in my head as to what qualifies as a "low-code tool". I'd like to know which low-code tools in particular the author has experience with.
Maybe it’s just me, but I assumed almost all devs with basic coding ability would be against low code. It has so many issues, from poor version control to never (and I do mean never - would love to be proven wrong) doing more than or even meeting the feature set of whatever competing “some code” solution offers.
In the end, you end up with either less skilled people getting in too deep, or highly skilled people unable to fully avail their skills. I get the appeal, but it always seemed like a local optima to me. It turns out code is a pretty good interface.
That's what people don't seem to get. "Low code" is literally just a software library with a gui on top.
They could just provide the software library as a standalone but then there's too much competition and the competition is often free to use. So they don't even bother because their whole product is redundant without the GUI, and the GUI itself is just a pointless obstacle to a developer.
Man, y'all haven't been around software consulting long enough. First, you have to sell low code based on the premise that you don't need coders to make your software. Than, for custom functionality, you explain that you need developers on the platform to get certified. Finally, you make sure to not document anything so that consulting firms with legacy experience have a monopoly on developer talent in order to keep them happy and recommending your software to others to score large consulting contracts.
Everyone is happy! Especially the people who actually have to use the software made this way! As we all know, enterprise software has a reputation for being extremely user friendly...
Talend is an ETL tool: Extract data from a data source (file, database, API), Transform it, and Load it into another data source (file, database, API), all in a pipeline. Talend's happy path is the same as Unix shell's happy path: A pipeline of data with no side-effects and no globals. Try to deviate from that and you hit walls, some more climbable than others.
For example, Talend absolutely will not allow you to re-combine a pipeline you've split; you can combine two separate data sources, and you can split to two separate sinks, but you absolutely cannot go from one pipeline to two pipelines back down to one.
The saving grace is that Talend is fundamentally a GUI for writing Java. You can see the Java it's writing, and you can add your own Java in a few ways, from adding jar files to just plopping a pipeline component that allows you to insert your own Java into the big God Method that the rest of your pipeline helping to form. Be sure you know how scoping works if you do that.
In extremis, you can "use Talend" in that you use the Talend GUI as an Eclipse IDE to write the one pipeline component that does everything because it contains all of the useful Java code. You can use it the way I often used it, to take care of some tedious "plumbing" code to route the pieces of data created by the hand-written component to their respective outputs, including handling some minor output conditioning that can be done in a stateless fashion. It can even be used as it was intended to be used, as odd as that sounds.
[+] [-] dexwiz|2 years ago|reply
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.
[+] [-] siliconc0w|2 years ago|reply
* 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.
[+] [-] bb88|2 years ago|reply
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."
[+] [-] hanniabu|2 years ago|reply
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.
[+] [-] gghffguhvc|2 years ago|reply
[+] [-] maccard|2 years ago|reply
I think this is an artifact of "source code is text" that our current tools assume (and is invalid IMO).
Otherwise I agree
[+] [-] citrin_ru|2 years ago|reply
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).
[+] [-] anyonecancode|2 years ago|reply
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.
[+] [-] bsdpufferfish|2 years ago|reply
> 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.
[+] [-] netman21|2 years ago|reply
[+] [-] quickthrower2|2 years ago|reply
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.
[+] [-] haolez|2 years ago|reply
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 :)
[+] [-] prakhar897|2 years ago|reply
[+] [-] syndicatedjelly|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] MetaWhirledPeas|2 years ago|reply
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.
[+] [-] abeyer|2 years ago|reply
[+] [-] ozim|2 years ago|reply
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.
[+] [-] tonyedgecombe|2 years ago|reply
[+] [-] elicksaur|2 years ago|reply
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.
[+] [-] ctrlp|2 years ago|reply
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.
[+] [-] cgrealy|2 years ago|reply
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.
[+] [-] agentgumshoe|2 years ago|reply
[+] [-] quickthrower2|2 years ago|reply
[+] [-] _heimdall|2 years ago|reply
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.
[+] [-] jbsmith1|2 years ago|reply
[+] [-] tmn007|2 years ago|reply
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.
[+] [-] ubertaco|2 years ago|reply
I find that generally the answer is most often "no," which is kinda a nail in the coffin for serious usage of "low-code."
[+] [-] bruce511|2 years ago|reply
What im saying is that you should be wary of ignoring things that don't fit into your current work-flow, because sometimes that "critical" thing in your workload is less critical than you think.
[+] [-] ryanjshaw|2 years ago|reply
This is the version control/CD process I designed:
- We have a normal Git repository, hosted in Azure DevOps cloud
- Developers work in the "unmanaged" cloud-hosted Development environment
- When ready to move a set of changes forwards, the developer branches the repo, and runs a PowerShell script to export the solution from the Development environment to a local ZIP file, which is then automatically unzipped. The only other thing I do is reset the version number to 0.0.0 within the `solution.xml` file, because I'm pedantic and the code isn't necessarily a deployable build yet - it could be an intermediate piece of work.
- Developer reviews the changes, commits with a message that links to work items in Azure DevOps, and creates a pull request -- all standard stuff
- On the Azure DevOps side, once a PR is merged, we build a managed ZIP -- which is really just the same code, with a flag set and re-zipped up with a version number that matches the DevOps build number (in the Power Apps world, "managed" package deployments can't be customized on UAT/Production without explicit configuration allowing it)
- We then use all the normal Azure DevOps YAML pipeline stuff to move this between UAT, Staging and Production with user approvals etc. The Azure AD and Power Apps integration makes this very pleasant - everything is very easy to secure, and you don't need to pass secrets around.
- You can rollback to a specific commit using normal Git tooling or just redeploy a past build if there is one available.
That all being said, most people don't do the above. I should probably sell a training course, because it took quite some time to put all the pieces together. The bigger problems are planning ahead for changes without breaking stuff that is already live, because you generally only use 1 development environment for an entire team.
[+] [-] otabdeveloper4|2 years ago|reply
Does Node Red count?
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] bruce511|2 years ago|reply
Of course, just like say the SQL or NoSQL debate there are contexts where one wins, and another fails.
I did have to smile at this though;
>> "Now, rather than being to recruit from a large pool of ubiquitous, open-source language developers, the company has to find maintainers who are very specialized in this tool."
From a company point of view this is correct. You cant just discard programmers and get a cheap, out-sourced one as a replacement.
On the other hand, as a somewhat older programmer, I like the idea that I get more valuable with age not less. I like that I can't be replaced by some ubiquitous open source freelancer who works for $20 an hour.
For the record I've been working with a low-code tool for 30 years (since long before "low code" was even a description) and I've seen thousands of one-man companies be successful developing programs where the owners actual programming skills are, well, in most cases, somewhat poor.
Turns out, making something useful has more to do with fixing pain, and less to do either writing code.
And yes, all the points listed in the article, and these comments, are true. And ironically almost none of it actually matters.
There are a million reasons it -shouldn't- work and yet, somehow, at least in my world it does.
[+] [-] jwoq9118|2 years ago|reply
[+] [-] doubloon|2 years ago|reply
VBA (Visual Basic available in Excel and Outlook) had a lot of the same issues as low code, as in no version control, no workflow for review or continuous testing and integration, no ability to do lots of custom things, that did not stop it from running the planet. I mean if you did the VBA version of Thanos-snapping half of all VBA code out of existence, most of society would cease to function within a week.
Power Automate is going to replace VBA soon because VBA can no longer talk to web pages thanks to the end of Internet Explorer and lack of VBA updates. And like VBA, Power Automate has all of the same problems - no concept of code review, version control, history, logging, actually its worse.
VBA at least let you have custom Types and Classes but in Power Automate everything, literally everything, is a global variable. Power Automate is lower code than VBA. But I think it will be used even more.
Because it is already installed on every almost every office computer in the world. This is the only tool ordinary Ops people will have available to them to automate stuff, so that is what will get used.
[+] [-] phamilton4|2 years ago|reply
Then I found out the developers assigned to working on the low/no code parts had a component where they could write Java inside their low code process. There were hundreds of lines of code in each business process in the low code parts. They were writing giant methods in their process wired up by the true low/no code part.
To make matters worse the tool did not support unit testing of the custom code.
It ended up being like dozer mapping entity to entity and then passed along to custom code. All wrapped in some crummy UI. It produced a jar file which would be deployed anyways.
Maybe the tools are better now. We had some Tibco product at the time.
[+] [-] bazil376|2 years ago|reply
[+] [-] Eji1700|2 years ago|reply
It is so so so close to being a silver bullet tool for quick front end crud that can use your AD to authenticate.
Instead though, it’s got the most absurd pricing model that even their own reps don’t understand and is missing critical or basic features, requiring strange workarounds (fucking UTC dates vs what’s actually in the DB).
They USED to have no way to reuse code as well but they fixed that.
I feel like the issue is they’re still too married to basically low/no code environments.
Having a “I’m going to need to do a custom script in whatever” option would smooth out the edges so much
[+] [-] beckingz|2 years ago|reply
Power Automate is great, but PowerApps is just a mess where every click in the dev interface takes like 5 seconds. On paper it looks so good, but in practice it is so painful to get that on paper performance and functionality.
[+] [-] YurgenJurgensen|2 years ago|reply
[+] [-] fulafel|2 years ago|reply
[+] [-] syndicatedjelly|2 years ago|reply
[+] [-] debarshri|2 years ago|reply
Eventually we moved to nextjs and vercel. We are faster with iterating on our landing page as well as any engineer can be pulled into the implementation.
All lowcode platforms are great in basic usecases but fails when the usecases because complex.
[+] [-] fnordpiglet|2 years ago|reply
[+] [-] JonChesterfield|2 years ago|reply
[+] [-] simonw|2 years ago|reply
[+] [-] appplication|2 years ago|reply
In the end, you end up with either less skilled people getting in too deep, or highly skilled people unable to fully avail their skills. I get the appeal, but it always seemed like a local optima to me. It turns out code is a pretty good interface.
[+] [-] sfn42|2 years ago|reply
They could just provide the software library as a standalone but then there's too much competition and the competition is often free to use. So they don't even bother because their whole product is redundant without the GUI, and the GUI itself is just a pointless obstacle to a developer.
[+] [-] GabeIsko|2 years ago|reply
Everyone is happy! Especially the people who actually have to use the software made this way! As we all know, enterprise software has a reputation for being extremely user friendly...
[+] [-] msla|2 years ago|reply
Talend is an ETL tool: Extract data from a data source (file, database, API), Transform it, and Load it into another data source (file, database, API), all in a pipeline. Talend's happy path is the same as Unix shell's happy path: A pipeline of data with no side-effects and no globals. Try to deviate from that and you hit walls, some more climbable than others.
For example, Talend absolutely will not allow you to re-combine a pipeline you've split; you can combine two separate data sources, and you can split to two separate sinks, but you absolutely cannot go from one pipeline to two pipelines back down to one.
The saving grace is that Talend is fundamentally a GUI for writing Java. You can see the Java it's writing, and you can add your own Java in a few ways, from adding jar files to just plopping a pipeline component that allows you to insert your own Java into the big God Method that the rest of your pipeline helping to form. Be sure you know how scoping works if you do that.
In extremis, you can "use Talend" in that you use the Talend GUI as an Eclipse IDE to write the one pipeline component that does everything because it contains all of the useful Java code. You can use it the way I often used it, to take care of some tedious "plumbing" code to route the pieces of data created by the hand-written component to their respective outputs, including handling some minor output conditioning that can be done in a stateless fashion. It can even be used as it was intended to be used, as odd as that sounds.