No-code or low-code still means you're creating software, even if you're using a drag-and-drop UI to do so. And if you're building software, you're going to want things like version control, environments, code review, etc. Unfortunately, most of these tools have zero ability to do these things, or have really half-baked imitations of them, and as a result the apps you've built in no-code/low-code are unable to scale as your company grows.
I co-founded a company called Airplane (https://www.airplane.dev/) which is essentially a low-code platform for building internal tools. But unlike other low-code platforms, the underlying representation of the stuff you build in Airplane is still just normal Python/JS/etc code that you can put in your monorepo, version control, write unit tests against, etc. As a result, there's a lot less vendor lock-in and eng teams can collaborate better at scale. You also don't hit the complexity ceiling that this article refers to.
I don't think Airplane needs to be unique in this regard. Other low-code platforms could allow user-friendly drag-and-drop interactions while still having underlying code-based representations that allow users to get the best of both worlds. I think more no-code/low-code platforms will be built in the future with this in mind.
These are good points. I have seen this over and over again - e.g. in a SaaS which is data configured, how do you a) develop and test your work in a sandbox instance, then b) ship those changes across to a prod instance.
This is especially complex in highly data driven platforms, e.g. when you can set up custom fields, then base your custom screens on those fields. Then you want to move a screen from one instance to another and it is dependant on several custom fields which may or may not be already present, but may not be at the latest version.
Unfortunately virtually no customers nor RFPs ask about these things, so they are a low priority until late in the piece and most platforms do a shit job of it.
Your approach is interesting, though most customers in our space at least would blanch if you said words like Python or JS to them, and would not know their git from their got.
Using code as the underlying format for low-code/no-code products is common and long-practiced; sometimes editable and exposed to the user, sometimes just to take advantage of existing code/text tooling.
People have been building NCLC systems for decades, but they tend to thrive best when they settle into a specific domain focus.
At that point, nobody outside the domain hears about them and nobody inside the domain even thinks of them in the terminology of “no-code low-code”
If you start squinting though,
you can spot them all over the place.
> No-code or low-code still means you're creating software, even if you're using a drag-and-drop UI to do so. And if you're building software, you're going to want things like version control, environments, code review, etc. Unfortunately, most of these tools have zero ability to do these things, or have really half-baked imitations of them, and as a result the apps you've built in no-code/low-code are unable to scale as your company grows.
This.
A phrase that captures this sentiment is that no-code and low-code is "Duck Programming:" It may be marketed as being not-programming, but if it walks like programming and swims like programming and quacks like programming, it's programming. And the code itself is just part of the practice of programming:
> I don't think Airplane needs to be unique in this regard. Other low-code platforms could allow user-friendly drag-and-drop interactions while still having underlying code-based representations that allow users to get the best of both worlds. I think more no-code/low-code platforms will be built in the future with this in mind.
I personally don't feel like this is the future. It's similar to storing a Word document's XML in source code. The way the visual editing and thinking works doesn't map to the text-based storage format, which then makes source code control little more than backup since it becomes difficult to tell what actually changed. Maybe this doesn't apply to Airplane though, so what I'm saying is more general for visual tools and programming languages.
There's no reason why visual tools and programming languages can't have visual comparison tools. Text is not the end all be all for things that can be compared.
The Airplane website gets cut off at the bottom on my laptop screen and because of how you overrided the scrolling I can't scroll down to see what I'm missing.
(Edit: actually I can scroll down but it still doesn't look good having it cut off like that.)
No code is a sales tactic to circumvent engineering folks who would correctly point out that the tool helps with 80% basic use cases and for the remaining 20% engineers have to be involved, but now instead of using python or something appropriate, they have to build it on top of this proprietary crippled framework.
I would argue that’s almost using no code solutions incorrectly because they are good for super initial mvp and validation by people who are non technical.
I’m trying to be an entrepreneur and I’m heavily technical. My struggle is on the business side and figuring out how to talk to people, but I can whip up fully functional mobile apps in like 10-20 hours because I’ve done that so many times, or build a solid backend that can easily scale to millions of people (granted that’s not so hard these days).
I know how hard and intimidating it is for people without a technical background to SHOW their idea beyond a image or PowerPoint. No code helps such people get something working out and I’m sure once they raise money for their validated idea they can hire engineers to build good long term solutions.
I’ve never raised money so idk if that’s reality but I don’t think it’s purely marketing. It’s a valid solution for some people.
Anyone can put videos on YouTube to start but once they find their audience and grow the quality and production of the channel grows as well. No code is the same way. Start with what you can like your smartphone and focus on the content, until you’re big enough to have a team and nice gear.
Engineers end up having to be involved anyway. The marketers and business people who slap something together in no-code don't realize that maintenance is the fat bit of the SDLC and they get to the point where they either get overwhelmed by the complexity of the spaghetti they've made, they don't know how to make changes to make the no-code thing do what they want, or they just get tired of maintaining the damn thing. So over the fence it goes to Software, because "they're good at this sort of thing". And now all they have to do is open JIRA tickets -- or send Excel sheets -- with the changes they want made.
So yeah. No-code. Easy solution for implementing functionality for managers and marketers -- who have a team of developers they can offload the hard grungy bits to.
There are plenty of low/no/visual code environments that are very successful and ergonomic, some of it is free software, some of it proprietary. I refer to it as visual programming from here on, because it is still a form of programming, the 'no code' term is marketing bull that detracts from that basic fact.
A common theme is that visual programming part is a restrictive DSL. So its about configuration and composition. The visual DSL is coded in a general purpose programming language. This model is I think quite powerful.
CMS: In Wordpress for example, themes and plugins are provided via code. Users have varying degrees of freedom depending on said themes/plugins to compose them.
Game Engines: In Unity visual programming is baked in. Programs can expose varying degrees of configurability. There are whole visual programming tools that let you define logic and behavior.
Speadsheets: Already quite powerful on their own, can be extended with scripting languages to gain new capabilities and triggers.
Video and Animations: Very typical for visual programming affordances. Users often get drag and drop interfaces to encode logic and behaviors.
etc...
These types of visual DSLs are incredibly successful, because they allow the programmers/engineers to solve the technically interesting, general problems and the domain experts to solve the domain specific problems.
However I agree that these tools often go too far, especially if they don't respect where a visual DSL should stop. Almost half of the work I get is from clients who previously used a "low-code" solution that got them into a mess, which was slow, brittle and unmaintainable.
No code tools all involve code. What they skip or dont involve are as many decisions and combinatorial effects that most “custom” software gets saddled with. For example in Retool if you want a table you get a table. One table. You can do a lot with it but you skip all the debate about how to do sorting, padding, styles, optimization, etc. Thats valuable.
Today no code seems more like visual basic 6. You drag and drop a bunch of stuff but realistically the meat of it requires more “advanced” knowledge but so does making a really good spreadsheet.
"realistically the meat of it requires more “advanced” knowledge but so does making a really good spreadsheet."
Same way the no-code developer doesn't want to learn the harder (more useful tool), the coding developer balks at learning a shitty, constraining language. There is no advantage to learning and using a no-code tool, which is likely incompatible with other tooling. The knowledge is "useless". Its the same aversion a programmer has to "sphaghetti code", not because it doesn't job the done, but because the knowledge is specialized in a non-useful manner.
The advantage most developers have found, is that most languages in the C++/Java tradition contain portable idioms - I don't care if you don't know the exact syntax for a for loop, an if statement, etc, once you've learnt to program once, a decent editor makes learning language syntax largely irrelevant. If I were hiring, I would care that you learnt and can use 3+ languages, I don't care which (code) langagues.
Now, there are plenty of idiosyncracies within textual languages - package managers, arbitrary gotchas due to language design (is it a reference? immutable? Does it live on the stack/heap/get auto collected?) - textual programmers shouldn't pretend like we live in a perfect world either. Most no code solutions though are going the complete opposite way of standardization. Its like being told "here's a jail, its your new home" and being supposed to be OK with that.
But to effectively use logic apps, you already have to have some knowledge of programming concepts. Flow control, parsing JSON/XML, parsing strings for meaningful triggers, calling API's.
A non-programmer would have a tough time. A programmer can build some pretty nice automation in almost no time at all.
I have yet to see a really good no-code solution that lets laymen be productive fast.
Excel probably hits the sweet spot for no-code vs low-code vs actual code. The transiion between the levels is completely seamless. If you want to add a complex calculation you can. If you really want to go crazy, you can too. Sure, it's not maintainable, you can't google the formula syntax (because it's translated) etc.
An important aspect of "no code" and "low code" isn't that there is no code being typed, there is "no coding tools", "no code compilation", "no code maintenance".
For no code to work one needs to be sure the framework can handle the requirements well, so customizations and workarounds wont be needed. To know the requirements sufficiently well one usually needs something in production, and years of experience with it. Why bother with no/low code then? If a more modern reimplementation is needed, it can be elegantly implemented in one of the bazzilion software stacks out there.
Another big disadvantage is lack of developers that like those kind of things and know them well. Those who do know those frameworks usually cost a lot more. Lots of those relatively niche things, such as mulesoft, are really just means to strengten the vendor lock in, and are sold to management, not engineering leads, on the premise of lessening the reliance on actual engineering. Which of course is a lie.
There’s always that one feature you need that’s not supported, and because you can’t just write some code to implement that feature, you’re stuck.
I’ve told this story here before, but I spent a day knocking out a couple of hundred lines of code to provision users in our system. But we wanted to trigger that provisioning from Okta, so someone else spent months implementing it in Okta’s no code system. And at the end of the day only that dev knew how to use it or how to fix it. We would have been much better off keeping it in Python.
Yup i'm pretty convinced the whole no code thing is just a scam.
People claim it's different from the old school no code and that it's faster to prototype in. Anything I look at is just the same drag and drop blocks of code, scrolling through a library of blocks of every function possible looking for an if statement, it really is a solution in search of a problem.
Management keep asking me to use it because "its easier to work with because you don't need to code!". I ask them if I already know how to code why would it be easier to use a new system I don't know? Blank faces all around.
I've worked a lot with no/low code solutions. There actually ended up being a lot of code! Surprise. Code is an interface between human desires and customising computers. There are infinite human desires, thus there will be a need for an interface that is 'code', even if it isn't a big file with scary ASCII characters.
My last project with a no-code solution was a visual designer where you flow-chart all the logic for workflows. At a very small scale, it might make sense but even for our meager need it was blown out so big that no one could really understand or modify it. And, worst of all, we were locked into this proprietary solution.
In the end, I re-wrote the entire project in regular code and the end result works better and is easier to modify. We don't need to pay expensive consultants anymore. No extra licensing fee. No special software/server/hosting requirements. And any programmer can work on it -- I can even put new hires on it.
It seems like one of the assumptions behind the no code hype is that product managers know exactly what clients want, and if they could just remove those pesky engineers from the situation they could deliver it. Which should be pretty funny to anyone who’s ever worked on a large greenfield software project.
The argument will continue to raise its head and it's a fair argument. But I think it is important that we evaluate on a per use case perspective.
For example, for simple CRUD apps/internal tools, use a low code platform like budibase (https://github.com/Budibase/budibase). For building a SaaS platform, with relative complexity, that your business is built on, I would venture towards code.
I remember a few (a lot) of years ago when Drupal / Wordpress came into the world. The same questions were asked, but today they solve a problem and they're simply easier to build a site with.
What I do feel is important, is the extensibility of the no/low code platform. I am the cofounder of Budibase and from the beginning, we set out to build an open source, extensible low code platform for a specific use case (crud apps/internal tools). We believe if a tool is a part of the development stack, it should be open source (for obvious reasons).
I don’t understand the need for no-code software development.
In my admittedly limited personal experience, any domain experts that were worth their salt were smart, and learning a programming language or two to the level required to make useful code contributions wasn’t really a problem.
A physicist often learns some programming language anyway, somewhere along their educational path.
I would be suspicious about the intelligence of someone who refused to use appropriate tools for specifying software behaviors claiming it too difficult. A baseball pro knows how to work and has a likely good mind, as does a culinary expert. I just don’t know anyone GOOD at a given field who isn’t also hardworking and smart.
What’s the big deal?
Why do we seek no-code software development solutions when code is the most precise concise manner to describe software behaviors?
Positive thing about no code is you can take a reasonably intelligent person with almost no technical no how but a willingness to learn and have them creating real software with a good low code solution in a month. Of course they will likely need someone with real experience to guide them for the first 3+ months. You need a really good training program though. Often the sales pitch for what these applications can deliver is overly aggressive though and the user is going to have to start to learn software architecture concepts eventually so everything is not a mess. I moved from full stack development to low-code and have been really impressed. There are of course limits, you can only use the components that have been created for the platform but overall you can produce some impressive applications. There are some very large corporations run by very smart people that have gone all in on low-code for the front end.
no-code software can work just fine if the scope is small - and that's where you find the target audience.
"back in the day" it was super easy to just slap together a GUI software using Visual Studio, Delphi, or whatever you had at hand. Really simple editors to make the GUI, and with basic programming knowledge, you programmed the various functions. Easy as pie.
If you wanted some software to run on a website, you could do the same with Java Applets - if you knew some java.
Again, this is stuff that non-programmers could learn in a fairly short amount of time. Business analysts, professors, engineers, whatever.
But what about these days? Well, even if you're smart - even if you know some basic programming - EVEN if you have the will, webdev is a fucking nightmare if you want something that's not static or very basic. The hoops you have to jump through, just to get your idea ported to a website.
These people are not going to write large applications or services that needs to be fast, scale big, be fully tested, etc. They mostly need some quick and dirty apps that can solve things, and without a too steep learning curve.
I'm wondering if anyone reading this thread (maybe ones who are shaking their head as they do so) knows of an existing meme for things of this sort. 'Snake oil' is the completely wrong metaphor here.
I'm thinking Greek mythology, sirens perhaps.
Learning curves that start with a cliff tend to be self-limiting. Lots of people nope out without even really trying. When you push it out to the horizon people miss it, often at their own peril, and at great profit for Salesforce, uh, I mean, for the vendor. The anonymous vendor.
I tried Appsmith, Budibase and a few others, because I had a need for some admin UI for a startup, and I thought that low-code would get me there quickly. I thought I could take a shortcut. I'm an experienced coder, so my biases surely play a role here. I was expecting these low-code tools to offer abstractions to make the effort for low-complexity problems very low (like the article suggests). Instead, I found that they were really just a point-and-click version of the code writing I'd otherwise do. All the complexity was still there (at which time the ergonomics of the tool becomes very important, and let's just say... that didn't help). I think the article is thus also flawed in some of its assumptions and conclusions.
There seems to be a rise of these low-code tools, and something good may certainly come from it. But when I looked at them (approx. 9 months ago), it just simply wasn't "there" yet. I also don't think that what they offer in 2022 is much better an experience than what I did in 2002 with Microsoft Access (which I've left behind me long since).
I wanted to love Appsmith but I kept running into telemetry code, including a hard coded segment id baked right into the base docker image. Sorry, but I can't defend your business needs during security review.
I've had the displeasure of re-implementing some awful systems written in a no-code platform.
If you're using low-code, you're still writing software, and good software is more than a bunch of if statements and function calls, it's a well-considered and understandable architecture too (or it should be)
Low-code makes it easy for non-programmers to write systems, but there's no reason you would expect these non-programmers to understand how to architect these sytems well. This (IMO) is why systems written in low-code tools often become unmaintainable piles of mush.
The problem with code vs no-code is that the only barrier it removes is the code. The “code” is the easy part.
Coding is like writing a story in a way and imagining the story is what’s hard. Whether it’s written in code, pictures, graphs, or grunts is irrelevant. No-code will not make a good story teller. Sure you will lower the barrier for those with little imagination telling small tales, but it will not help in the epic adventures.
This is an understatement. Main problems are versioning, collaborating, maintenance.
Coding is like writing a story with other authors, with each chapter inspired by /writing-prompt, and publishing the whole book with new ISBN for every typo.
If app-publishing is fast, {no|low}-code wins. The obvious caveat being, that it is not a full fledged system where you can build yet another no-code platform on top of it.
So I was recently very attracted to some no-code platforms because I have a simple cloud based application that interacts with some APIs, authenticating with OAuth2. I know what I want to do, but as a primarily systems developer with very limited web development, I have no interest or desire to start creating websites to perform user authentication (not least when I only have one user), along with storing credentials securely, running a server etc etc.
It feels to me that some service should exist that provides the API plumbing I need so I can just write the code that processes data and writes to APIs. Things like zapier can probably do it, but then it becomes a hassle to add arbitrary code to the mix. Does anyone know of anything that can help here?
Problem 1: The point where the two curves meet is almost always met sooner in a projects dev-cycle than expected.
Problem 2: Coding something is one thing. Version-Controlling it, intergrating it into a deployment chain, running it in different Environments, Reviewing it, scaling it are a collection of entirely different beasts.
Problem 3: As soon as the project hits a requirement where there is no lownocode solution (eg. integration with some custom monitoring system with no premade hooks available), the effort required goes through the roof, because now we have to interface the two worlds with each other, adding a layer of complexity that wouldn't exist if the entire thing had been code from the beginning.
The idea of using spreadsheets is very clear, data in tabular form and charts. If that is the requirement, most low-code platforms would suffice too.
But, then the expectations are not articulated and managed properly, and management being management, thinks that they can retire grumpy oldies who build complex app in favor of low-code apps.
Which is itself built on the flattened rubble of 4GLs. A couple companies made a go of round-tripping from UML to code, but you know someone was hoping to stop that merry-go-round on the pretty pictures.
I'm sure there is a place for no-code tools, but LabView left a very sour taste in my mouth after seeing how much it was abused to do things it was pretty much the worst tool imaginable for.
A lot of negativity towards no-code in the comments, which I think is misguided. These tools also makes developers lives easier and help us serve the customer better.
Sure, when a project react a certain level of complexity, no-code is not enough and you need real code, and the transition might be painful. But most tasks are simple. 80% of all solution might never reach the level of complexity where code is required. For the remaining 20% it means we now have a working prototype which represent the requirements of the customer, which is much better than starting from scratch with vague specifications.
Web site builders like Wordpress is the classic example. Once even trivial websites required programming. Now most websites can be built in such a system.
Unqork uses Unqork to deliver most all of it's SDLC capabilities because yes, as some folks stated to start this: no-code is still creating software and you need visibility, governance, etc around it.
[+] [-] raviparikh|3 years ago|reply
I co-founded a company called Airplane (https://www.airplane.dev/) which is essentially a low-code platform for building internal tools. But unlike other low-code platforms, the underlying representation of the stuff you build in Airplane is still just normal Python/JS/etc code that you can put in your monorepo, version control, write unit tests against, etc. As a result, there's a lot less vendor lock-in and eng teams can collaborate better at scale. You also don't hit the complexity ceiling that this article refers to.
I don't think Airplane needs to be unique in this regard. Other low-code platforms could allow user-friendly drag-and-drop interactions while still having underlying code-based representations that allow users to get the best of both worlds. I think more no-code/low-code platforms will be built in the future with this in mind.
[+] [-] beachy|3 years ago|reply
This is especially complex in highly data driven platforms, e.g. when you can set up custom fields, then base your custom screens on those fields. Then you want to move a screen from one instance to another and it is dependant on several custom fields which may or may not be already present, but may not be at the latest version.
Unfortunately virtually no customers nor RFPs ask about these things, so they are a low priority until late in the piece and most platforms do a shit job of it.
Your approach is interesting, though most customers in our space at least would blanch if you said words like Python or JS to them, and would not know their git from their got.
[+] [-] swatcoder|3 years ago|reply
Using code as the underlying format for low-code/no-code products is common and long-practiced; sometimes editable and exposed to the user, sometimes just to take advantage of existing code/text tooling.
People have been building NCLC systems for decades, but they tend to thrive best when they settle into a specific domain focus.
At that point, nobody outside the domain hears about them and nobody inside the domain even thinks of them in the terminology of “no-code low-code”
If you start squinting though, you can spot them all over the place.
[+] [-] a4isms|3 years ago|reply
This.
A phrase that captures this sentiment is that no-code and low-code is "Duck Programming:" It may be marketed as being not-programming, but if it walks like programming and swims like programming and quacks like programming, it's programming. And the code itself is just part of the practice of programming:
https://raganwald.com/2012/01/08/duck-programming.html
HN discussion:
https://news.ycombinator.com/item?id=3442419
(The original submission was on a now-defunct site, the link above is current.)
[+] [-] bmitc|3 years ago|reply
I personally don't feel like this is the future. It's similar to storing a Word document's XML in source code. The way the visual editing and thinking works doesn't map to the text-based storage format, which then makes source code control little more than backup since it becomes difficult to tell what actually changed. Maybe this doesn't apply to Airplane though, so what I'm saying is more general for visual tools and programming languages.
There's no reason why visual tools and programming languages can't have visual comparison tools. Text is not the end all be all for things that can be compared.
[+] [-] easrng|3 years ago|reply
(Edit: actually I can scroll down but it still doesn't look good having it cut off like that.)
[+] [-] glouwbug|3 years ago|reply
[+] [-] snidane|3 years ago|reply
[+] [-] moomoo11|3 years ago|reply
I’m trying to be an entrepreneur and I’m heavily technical. My struggle is on the business side and figuring out how to talk to people, but I can whip up fully functional mobile apps in like 10-20 hours because I’ve done that so many times, or build a solid backend that can easily scale to millions of people (granted that’s not so hard these days).
I know how hard and intimidating it is for people without a technical background to SHOW their idea beyond a image or PowerPoint. No code helps such people get something working out and I’m sure once they raise money for their validated idea they can hire engineers to build good long term solutions.
I’ve never raised money so idk if that’s reality but I don’t think it’s purely marketing. It’s a valid solution for some people.
Anyone can put videos on YouTube to start but once they find their audience and grow the quality and production of the channel grows as well. No code is the same way. Start with what you can like your smartphone and focus on the content, until you’re big enough to have a team and nice gear.
[+] [-] bitwize|3 years ago|reply
So yeah. No-code. Easy solution for implementing functionality for managers and marketers -- who have a team of developers they can offload the hard grungy bits to.
[+] [-] dgb23|3 years ago|reply
A common theme is that visual programming part is a restrictive DSL. So its about configuration and composition. The visual DSL is coded in a general purpose programming language. This model is I think quite powerful.
CMS: In Wordpress for example, themes and plugins are provided via code. Users have varying degrees of freedom depending on said themes/plugins to compose them.
Game Engines: In Unity visual programming is baked in. Programs can expose varying degrees of configurability. There are whole visual programming tools that let you define logic and behavior.
Speadsheets: Already quite powerful on their own, can be extended with scripting languages to gain new capabilities and triggers.
Video and Animations: Very typical for visual programming affordances. Users often get drag and drop interfaces to encode logic and behaviors.
etc...
These types of visual DSLs are incredibly successful, because they allow the programmers/engineers to solve the technically interesting, general problems and the domain experts to solve the domain specific problems.
However I agree that these tools often go too far, especially if they don't respect where a visual DSL should stop. Almost half of the work I get is from clients who previously used a "low-code" solution that got them into a mess, which was slow, brittle and unmaintainable.
[+] [-] iostream24|3 years ago|reply
[+] [-] thinkingkong|3 years ago|reply
Today no code seems more like visual basic 6. You drag and drop a bunch of stuff but realistically the meat of it requires more “advanced” knowledge but so does making a really good spreadsheet.
[+] [-] smaudet|3 years ago|reply
Same way the no-code developer doesn't want to learn the harder (more useful tool), the coding developer balks at learning a shitty, constraining language. There is no advantage to learning and using a no-code tool, which is likely incompatible with other tooling. The knowledge is "useless". Its the same aversion a programmer has to "sphaghetti code", not because it doesn't job the done, but because the knowledge is specialized in a non-useful manner.
The advantage most developers have found, is that most languages in the C++/Java tradition contain portable idioms - I don't care if you don't know the exact syntax for a for loop, an if statement, etc, once you've learnt to program once, a decent editor makes learning language syntax largely irrelevant. If I were hiring, I would care that you learnt and can use 3+ languages, I don't care which (code) langagues.
Now, there are plenty of idiosyncracies within textual languages - package managers, arbitrary gotchas due to language design (is it a reference? immutable? Does it live on the stack/heap/get auto collected?) - textual programmers shouldn't pretend like we live in a perfect world either. Most no code solutions though are going the complete opposite way of standardization. Its like being told "here's a jail, its your new home" and being supposed to be OK with that.
[+] [-] RajT88|3 years ago|reply
I love logic apps. I move mountains with them.
But to effectively use logic apps, you already have to have some knowledge of programming concepts. Flow control, parsing JSON/XML, parsing strings for meaningful triggers, calling API's.
A non-programmer would have a tough time. A programmer can build some pretty nice automation in almost no time at all.
I have yet to see a really good no-code solution that lets laymen be productive fast.
[+] [-] alkonaut|3 years ago|reply
Excel probably hits the sweet spot for no-code vs low-code vs actual code. The transiion between the levels is completely seamless. If you want to add a complex calculation you can. If you really want to go crazy, you can too. Sure, it's not maintainable, you can't google the formula syntax (because it's translated) etc.
An important aspect of "no code" and "low code" isn't that there is no code being typed, there is "no coding tools", "no code compilation", "no code maintenance".
[+] [-] scrame|3 years ago|reply
[+] [-] aenis|3 years ago|reply
For no code to work one needs to be sure the framework can handle the requirements well, so customizations and workarounds wont be needed. To know the requirements sufficiently well one usually needs something in production, and years of experience with it. Why bother with no/low code then? If a more modern reimplementation is needed, it can be elegantly implemented in one of the bazzilion software stacks out there.
Another big disadvantage is lack of developers that like those kind of things and know them well. Those who do know those frameworks usually cost a lot more. Lots of those relatively niche things, such as mulesoft, are really just means to strengten the vendor lock in, and are sold to management, not engineering leads, on the premise of lessening the reliance on actual engineering. Which of course is a lie.
[+] [-] wussboy|3 years ago|reply
I’ve told this story here before, but I spent a day knocking out a couple of hundred lines of code to provision users in our system. But we wanted to trigger that provisioning from Okta, so someone else spent months implementing it in Okta’s no code system. And at the end of the day only that dev knew how to use it or how to fix it. We would have been much better off keeping it in Python.
[+] [-] dangerface|3 years ago|reply
People claim it's different from the old school no code and that it's faster to prototype in. Anything I look at is just the same drag and drop blocks of code, scrolling through a library of blocks of every function possible looking for an if statement, it really is a solution in search of a problem.
Management keep asking me to use it because "its easier to work with because you don't need to code!". I ask them if I already know how to code why would it be easier to use a new system I don't know? Blank faces all around.
[+] [-] beej71|3 years ago|reply
It's cyclic. :)
But one of these days (I figure with the help of machine learning), it'll actually reach Star Trek levels and we'll be out of a job.
[+] [-] bigDinosaur|3 years ago|reply
[+] [-] wvenable|3 years ago|reply
In the end, I re-wrote the entire project in regular code and the end result works better and is easier to modify. We don't need to pay expensive consultants anymore. No extra licensing fee. No special software/server/hosting requirements. And any programmer can work on it -- I can even put new hires on it.
[+] [-] horns4lyfe|3 years ago|reply
[+] [-] hinkley|3 years ago|reply
[+] [-] marcosdumay|3 years ago|reply
What does not always happen, but is not rare either.
[+] [-] foxbee|3 years ago|reply
For example, for simple CRUD apps/internal tools, use a low code platform like budibase (https://github.com/Budibase/budibase). For building a SaaS platform, with relative complexity, that your business is built on, I would venture towards code.
I remember a few (a lot) of years ago when Drupal / Wordpress came into the world. The same questions were asked, but today they solve a problem and they're simply easier to build a site with.
What I do feel is important, is the extensibility of the no/low code platform. I am the cofounder of Budibase and from the beginning, we set out to build an open source, extensible low code platform for a specific use case (crud apps/internal tools). We believe if a tool is a part of the development stack, it should be open source (for obvious reasons).
[+] [-] iostream24|3 years ago|reply
I would be suspicious about the intelligence of someone who refused to use appropriate tools for specifying software behaviors claiming it too difficult. A baseball pro knows how to work and has a likely good mind, as does a culinary expert. I just don’t know anyone GOOD at a given field who isn’t also hardworking and smart.
What’s the big deal? Why do we seek no-code software development solutions when code is the most precise concise manner to describe software behaviors?
[+] [-] wonderwonder|3 years ago|reply
[+] [-] TrackerFF|3 years ago|reply
"back in the day" it was super easy to just slap together a GUI software using Visual Studio, Delphi, or whatever you had at hand. Really simple editors to make the GUI, and with basic programming knowledge, you programmed the various functions. Easy as pie.
If you wanted some software to run on a website, you could do the same with Java Applets - if you knew some java.
Again, this is stuff that non-programmers could learn in a fairly short amount of time. Business analysts, professors, engineers, whatever.
But what about these days? Well, even if you're smart - even if you know some basic programming - EVEN if you have the will, webdev is a fucking nightmare if you want something that's not static or very basic. The hoops you have to jump through, just to get your idea ported to a website.
These people are not going to write large applications or services that needs to be fast, scale big, be fully tested, etc. They mostly need some quick and dirty apps that can solve things, and without a too steep learning curve.
[+] [-] hinkley|3 years ago|reply
I'm thinking Greek mythology, sirens perhaps.
Learning curves that start with a cliff tend to be self-limiting. Lots of people nope out without even really trying. When you push it out to the horizon people miss it, often at their own peril, and at great profit for Salesforce, uh, I mean, for the vendor. The anonymous vendor.
[+] [-] sverhagen|3 years ago|reply
There seems to be a rise of these low-code tools, and something good may certainly come from it. But when I looked at them (approx. 9 months ago), it just simply wasn't "there" yet. I also don't think that what they offer in 2022 is much better an experience than what I did in 2002 with Microsoft Access (which I've left behind me long since).
[+] [-] victor9000|3 years ago|reply
For example: https://github.com/appsmithorg/appsmith/blob/8edb278b755cc5f...
[+] [-] bjpirt|3 years ago|reply
If you're using low-code, you're still writing software, and good software is more than a bunch of if statements and function calls, it's a well-considered and understandable architecture too (or it should be)
Low-code makes it easy for non-programmers to write systems, but there's no reason you would expect these non-programmers to understand how to architect these sytems well. This (IMO) is why systems written in low-code tools often become unmaintainable piles of mush.
[+] [-] cassac|3 years ago|reply
Coding is like writing a story in a way and imagining the story is what’s hard. Whether it’s written in code, pictures, graphs, or grunts is irrelevant. No-code will not make a good story teller. Sure you will lower the barrier for those with little imagination telling small tales, but it will not help in the epic adventures.
[+] [-] f0c1s|3 years ago|reply
This is an understatement. Main problems are versioning, collaborating, maintenance.
Coding is like writing a story with other authors, with each chapter inspired by /writing-prompt, and publishing the whole book with new ISBN for every typo.
If app-publishing is fast, {no|low}-code wins. The obvious caveat being, that it is not a full fledged system where you can build yet another no-code platform on top of it.
[+] [-] hgomersall|3 years ago|reply
It feels to me that some service should exist that provides the API plumbing I need so I can just write the code that processes data and writes to APIs. Things like zapier can probably do it, but then it becomes a hassle to add arbitrary code to the mix. Does anyone know of anything that can help here?
[+] [-] usrbinbash|3 years ago|reply
Problem 2: Coding something is one thing. Version-Controlling it, intergrating it into a deployment chain, running it in different Environments, Reviewing it, scaling it are a collection of entirely different beasts.
Problem 3: As soon as the project hits a requirement where there is no lownocode solution (eg. integration with some custom monitoring system with no premade hooks available), the effort required goes through the roof, because now we have to interface the two worlds with each other, adding a layer of complexity that wouldn't exist if the entire thing had been code from the beginning.
[+] [-] moonchrome|3 years ago|reply
[+] [-] d--b|3 years ago|reply
[+] [-] f0c1s|3 years ago|reply
But, then the expectations are not articulated and managed properly, and management being management, thinks that they can retire grumpy oldies who build complex app in favor of low-code apps.
[+] [-] hinkley|3 years ago|reply
[+] [-] dymk|3 years ago|reply
[+] [-] 29athrowaway|3 years ago|reply
[+] [-] xedrac|3 years ago|reply
[+] [-] zoomzoom|3 years ago|reply
Bottom line up front, I believe that we don’t want to lose the proven expressiveness of code.
[+] [-] goto11|3 years ago|reply
Sure, when a project react a certain level of complexity, no-code is not enough and you need real code, and the transition might be painful. But most tasks are simple. 80% of all solution might never reach the level of complexity where code is required. For the remaining 20% it means we now have a working prototype which represent the requirements of the customer, which is much better than starting from scratch with vague specifications.
Web site builders like Wordpress is the classic example. Once even trivial websites required programming. Now most websites can be built in such a system.
[+] [-] heax|3 years ago|reply
[+] [-] the_uncoder|3 years ago|reply
Unqork uses Unqork to deliver most all of it's SDLC capabilities because yes, as some folks stated to start this: no-code is still creating software and you need visibility, governance, etc around it.
https://www.youtube.com/watch?v=LkXPakTWAEQ