No code tools have been on the market for quite some time, but it seems that recently they gained even more attention. Will they replace developers, or will developers adjust? Maybe this is an opportunity for the developers themselves... I’m curious, what is your opinion on no code or low code tools.
Relational Databases are essentially no-code replacements for b-trees. I have worked in several companies where the managers could not do any coding, but could wipe out an SQL query to get some data point they needed. Heck building an UI that generates SQL queries for you based on some DB schema isn't even that hard. Relational databases removed the need for most b-tree and binary-streams manipulation coders in the 90s yet the demand for all types of coders (even b-tree and binary-streams coding!) only increased
As tools evolve programmers get exponentially more productive, but they will still be coding. They might be coding different things though because what we do today can now be done by a tool
People point UI work will be replaced, I actually highly doubt that, unless there is an standardisation of UI-toolkit like we used to have in the windows 98 days (which seems incredibly unlikely). Remember Delphi and Visual Basic? Sure there was code in there, but very rarely did you need actually need to write UI-code like animating a text box around, most of it was business logic code
If anything the UI landscape is changing to be more custom for each app instead of consolidating. I expect UI coding will look very different in the future though, more focused on unique user interactions and animations instead of API calls and Form glue code
funnily enough there are plenty of coding necessary to get around relational database limitations in large-scale projects. If anything low-code and no-code tools increase the demand for coders even more because more projects become possible at a good return on investment
This is a cycle that repeats every 10-12 years imo.
And then, after 2 or 3 years, the hype is gone, because it turns out that
a) Complexity can be hidden and displaced but not eliminated
b) Vendor Lock-In issues
c) Interoperability issues with existing tools, platforms and systems (ever tried to version-control a nolo-code project?)
and last but certainly not least
d) As projects get bigger and requirements pile up, at some point there is a requirement not satisfied by the platform; then the dance to somehow interface it with "some code" starts, then the next requirement comes along, and the next, and at some point somehow aska the question "Wouldn't it be simpler to rewrite this in XYZ" and at that point the cycle usually ends.
That doesn't mean that these things do not add value. The hype is usually gone after each cycle, but useful things that help a lot of people making things they would't have otherwise made remain.
Low code is what we are doing every day with modern programming languages and developer tools. We write a fraction of the code someone had to write 30 years ago for the same functionality. In that regard, the future is already here.
And developers haven't been replaced, and it is unlikely that they will be. But the role has already changed. A bigger part of being a developer is to understand business requirement and talking to customers (internal and external), while previously you could rely on your precious technical skills to be irreplaceable.
Finally, for many people No Code seems to mean "graphical code". That is certainly nothing new and is great for some things, like developing interfaces and I have seen some reasonably successful ones for developing database schemas. But for expressing flow and logic, text still rules supreme (for a number of reasons).
We can look to Salesforce for how this will likely play out - they aren't the only no-code platform out there, but they are big and have been around a while, so their dev culture has had a long time to evolve.
In that world, most devs work primarily in the no-code portion of that platform, maybe with some basic coding skills. That group does the majority of app dev work. But there is a smaller percentage of people who do write code, and who do the work that goes beyond what the no-code features can do.
So most other platforms will likely match - a wide swath of people, functions, and apps are no-code, and you absolutely can succeed both doing no-code work for your job, with most businesses not needing more than that. But there will always be another layer underneath the non-code to let businesses who need more to have coders who add more features.
For relatively simple projects it's already happening, I recently booked a doctors appointment online using a site built with a no-code tool. Turns out the physician built it himself and admitted to having very little in the way of technical knowledge. Not so long ago he would've had to have hired a fullstack developer for the job.
Would a hospital booking thousands of appointments in a given day be able to get by with the same no-code solution? No, but there's only going to be so many of them.
I still think no one has fully crack the low code / no code tools on the Web. You cant have a No Code solution that doesn't offer Low Code function. And you cant have a Low Code solution that you cant expand to Full Stack Code.
Think of it like Game Engine, where you could make games with editors, and then you add some code, all the way to some AA Games ( May be not AAA ).
May be a better example for the Web would be something like Yahoo Pipes.
I get what you are saying, but specifically with Bubble[0], I've been able to walk a far longer part of the stretch from low code to full stack code than it was possible in the past. It's crazy how easy it is to hook in custom JS components, etc.. I'd recommend it to anyone who is still in the validation phase of a product.
In the end we still had to ditch them, as the low-code cowboy coding didn't mesh well with the need for multiple environments and running tests in CI and backups, etc..
That is the last part of the whole thing. You should have the full code base of your No/Low Code product, so once you do grown out of the designed limit, you could actually dip into or hire programmers to do it. All while sending feedback to the product of what force you to get the full code base.
And I haven't see anything like that ( yet ). Because from a business perspective, you want your client to be locked into SaaS, but from a user perspective, they want to have the option to full control.
But I will take a look at bubble, seems interesting judging by the showcase.
I think there will always be a boundary with these tools where if you are building something complex you will reach a point in the project where you need something more advanced than the tool you're using can provide. For me at least, that was the spark to learn to code in the first place. You could call it the law of conservation of code, but I think there is a limitation on how complicated the output a no-code tool can create before it eventually becomes a code tool.
That said, for the chiropractor who needs a website to list his phone number, address, and services, I think a future where he doesn't need to hire a web designer and potentially get scammed (I've seen this a number of times) is a bright one, and I do think we're headed towards a future where the tools are good enough to make very basic front end dev work for situations like this obsolete.
These kind of no-code or low-code tools are VERY common in enterprise, like SAP, Salesforce, CMS solutions, IBM Tivoli products, and on and on. But companies are starting to realise that those tools often have some hard limits on what you can do and the problems they are solving get so complex that hacking the tool around to solve the problem becomes unsustainable. If anything even enterprise companies are pivoting away from this kind of tool towards custom-built software.
I call it the "army of consultants problem", sure you can use a low/no-code tool, but if your problem is complex or big enough you will eventually need an army of consultants specialised in said tool to maintain your solution and you will be limited by what the tool can do. Eventually you get to that point it becomes more expensive than just building custom, but by then your company is too invested in the tool and only a band-aid ripping can fix it. Most often than not ripping it out would kill the company/product if it happens too late. Thing is, the tools give the impression they are cheaper because you get a lot "out of the box", while a custom-built tool takes a long time to do anything useful
Reminds me an article I read once, it was about why My Space failed, it propositioned that the main reason was that they were using Dreamweaver and their product was so big and complex that the devs could no longer handle the complexity to add new features or fix performance problems. And the company as an organisation could not find enough dreamweaver devs because they needed an army of them
One of the main triggers for this is cloud infrastructure is so much better and cheaper today that a single developer can orchestrate a really complex system of services and servers in a few hours if he knows what he is doing. So the industry as a whole is shifting from "army of low skill specialised devs" to "low amount of highly skilled generalist devs". You can see it in the job openings, nobody wants to hire low-level anymore, or if they do it is to support legacy systems
of course it is a balancing act, plenty of companies use no-code or low-code tools for limited small-scale uses. Classic one is CMS, few companies have legitimate reasons to build their own custom CMS instead of using a SaaS one. You need to be at a scale where you have so much content written/managed by so many people that it makes sense to do custom. Or have exoteric types of content
It reminds me of a guy I interviewed who worked at a fashion brand as a software engineer, his job was to build a custom system to automate fitting photos of clothes to photos of people to put in the e-commerce site. Previously they did it manually with photoshop, but they needed an army of photoshop guys to do it. His solution was custom to the needs of the company (ie only the poses they needed), a generic SaaS solution, if it existed, would have probably been too complex to use or maintain
In general the Joel rule applies: "If it is core to your business, you want to do it in-house". Although I can think of a few exceptions, like payment/subscription flows for e-commerce. But heck I bet Amazon has their own custom payment/subscription systems for each market
This questions keeps coming up, and without knowing the specifics of the tools being discussed, the answer will always be "it depends".
I recently started using a no-code tool called Glide[0], because it emphasized that the starting point could be as simple as a Google Sheet. That data is pulled into the app's visual builder interface, so you can start playing around with filters and conditional logic to show/hide information.
Then you can set up user logins, Stripe integration and basic CRUD functionality with read/writes happening on the Gsheet. You can string together actions with Zapier and create calculated columns like you would on an Excel pivot table.
Ultimately, I can see myself creating a small community app using this tool, but not something that has hundreds of thousands of users, as then we get into tricky issues of vendor lock-in.
So IMO, the use case for something like this is for rapid prototyping and and an MVP. You wouldn't want your entire business hosted on someone else's platform, so as you get user feedback on the MVP, you should be talking to a dev about how to move off-platform: hosting, deployment, using a proper DB, security reviews ---- all the ugly stuff the no-code tool abstracted away.
I think it will eventually provide most of the scaffolding especially for frontend. Main resistance is with OG developers - new devs will embrace it going forward.
I remember when automatic cars came about - people who were used to manual shift resisted it, but now it’s almost silly to push back on automatic.
Another good example is house printing / prefabs - it’s just a matter of adoption but builders provide the resistance because of money they’ll loose.
I don't think they are. A manual car causes a constant overhead that is relatively easy to manage, at the same time the driver has to have their attention on the road anyway. A "yes-code" software development OTOH is very expensive and will happily be swapped away if there were an equally flexible and powerful alternative.
Maybe no-code it's more like autonomous driving: "big, if true" but not quite there yet?
I was talking to a youngin and mentioned that it wasn't exactly the same, but we've seen RAD, Access, FoxPro and other "low code/no code" environments before and it wasn't the end of code; generally as things changed it was harder to maintain these interfaces to actual code and they were commercial offerings that eventually fell apart because corporations don't do much indefinitely.
What problem are you solving? If you want to expose already existing data, text, pictures, or do simple transformations, no-code is good. If you need to develop your logic, gather conditionally data from different sources that needs to be parsed and so on, this gets complex and you'd better use a proper language.
No-code only means that the code is somewhere else and it has been nicely packaged for easy reuse. The moment you can't build it with lego, you can't do it with no-code. :)
I'm doing research, thus wanting to see what others think of it. I tried to spark conversation to see where/when/who and for what purpose people can use it.. (when is the exact time to switch from no code to for example hiring a developer)
Huge amounts of analysis and data-recording happen with people juggling spreadsheets, because they are easier for 'business/finance' people to learn how to use them vs. coding and databases.
I think there is huge potential for improved spreadsheets, either with generic things such as greater scalability/ability to schedule reports or with inbuilt capability for common tasks for specific industries.
They probably could, but it would be worse. I worked for a few years with the opposite, replacing spreadsheets with systems with custom interfaces, backed with databases, access control, real backups etc. The savings (in form of reduced need of manpower), quality and reliability increases have often been enormous for these customers.
Sure, but the question is one of stability and consistency.
Take data input: You want your front line workers to record every time they do thing X. They could go into a spreadsheet and increment the count by 1 (or add a new entry in the row each time) or they could pull out their phone and open an app and press +1X, with the option of -1X if they make a mistake.
airtable is a thing, thing is as these tools get more powerful they also become more complicated to use. It gets to the point you need one (or several) specialists in the tool to do the work and then you might as well build a custom system
One yet-to-be-mentioned element here is the dynamic of developer preference and resistance. As systems bifurcate into relatively cookie-cutter "lego"-like technical components (the Wixification of the entire stack via cloud, frameworks and no-code), vs the heavy-lift coding to make the framework "legos" themselves, a lot of the fun development is going to go away (development with a direct end-user feedback loop and the reward of solving some real-world problem). This dynamic also eliminates a good entry point for developers (basic apps and web sites), which allow them to build the knowledge to create and love those more sophisticated re-useable legos, because they understand the true pain of solving those original problems without them. I predict a big, negative impact on the future population of developers arriving to software from "creative" entry points, like design, marketing, or finance, because the bridge will be gone. What will be left are only formally educated engineers.
It's definitely 'a' future, in that there's no good reason why it would go away. It'll get better and better, but there'll always be something it can't do well.
For me, the key to a no-code solution is that it provides an escape hatch into code when necessary. If I have that, the no-code stuff is actually really nice.
We don't use Low or No Code solutions at work, but I wish we did. There's tons of automations we could do, however, because everything has to be a proper app with a proper deployment, etc, its a big job. I hope that Low/No Code solutions make it easier for a wide range of people to automate their jobs. I expect this will be accelerated with the next generation being more tech savvy.
We're already seeing similar parallel in Finance with End User Computing[0] where non-developers (traders, etc) are using tools like Python, Jupyter, etc as part of their jobs.
I don't ever see it replacing developers though. Maybe if your entire job is workflow automation, sure, but developers will focus on solutions that are difficult to do with Low/No Code tools.
Even if they take off, they're implemented in code, so they can't obsolete developers. Similar to the existence of cloud platforms not meaning there is no longer a need for platform dev and system administrators or even basic lab techs to physically install computing equipment. It just means for a sufficiently small business that doesn't want to roll its own infra, those roles are now employed by the cloud provider rather than the small business directly. Similarly, if no-code ever truly takes off, it just means devs who specialize in small business one-off websites won't be employed directly by small businesses and will work for no-code toolchain companies instead. The result will be consolidation and probably some amount of sector downsizing or else such products can't offer any real value, but it won't result in complete elimination of human labor.
Truth. Developers will always be needed and I don't think they'll ever get eliminated by no code tools. After all, someone has to create and develop these solutions. So it looks like programmers' jobs, responsibilities, and employment will gradually change. To be true these changes are already visible.
What an odd question to ask! Who do you think is going to code / maintain those "no-code" tools then? If for nothing else, this is one reason why you'll never obsolete developers.
But actually, if you think about it, the best you can do is that you raise the level of abstraction - that doesn't mean the new level will not need developers.
Of course, for certain common "boring" software will be no-code, which I'm actually quite happy about. Who would want to code the N+1st CRUD app over and over again?...
No-code is fantastic for basic websites and apps. Prototyping basic businesses has never been easier than with no-code tools that let people string together common functions.
The key is to know when it’s time to outgrow the no-code version and start a real custom implementation. Not all businesses will get there, but the developers need to know when it’s time to switch over.
Fortunately, replicating a no-code site as a custom solution is actually quite easy in most cases because the no-code building blocks have a lot of easy to use code library equivalents.
I think it will reach a point where it's similar to page builder. It works, sometimes that's all you need. But it's bloated, not always optimal, you will likely reach a point when it's clearly not enough.
In my opinion there is a market for it but they should not fall into the trap of trying to be generic (like bubble for example), when they do, they are quite hard to use that you might as well learn coding.
But for specific use cases building a simple and custom CRM, showing structured data, prototyping etc it's good.
I've been seeing ads for No Code products for decades. I've watched the various categories of development tools (IDEs, configuration management and version control systems, etc.) mature over the years.
Good development tools can be used to accelerate development when they help you leverage your knowledge of the system and technology. What I haven't seen them do is replace a deep understanding of how things work that's necessary to build scalable and performant software.
The tide of software is always turning from "requires custom development" towards "turnkey solutions exists." "No-code" is a buzzword that sits on one of the contours between the two.
Of course the web is/will be changing. The only interesting aspect of the web is that it expends so much effort changing it's fashion rather than it's form that this question even has to be asked.
Agree that no-code is a buzzword, and one that VC-backed plays like Webflow are using constantly as part of their marketing.
Salesforce and Wordpress are both "no-code" platforms that people have built businesses on. Fortunately they include the ability to write and edit code so you can go past the limitations of its off-the-shelf plugin libraries.
Development will still be hard intellectually, but much easier when you don’t have to deal with symbolic manipulation. I don’t think no code is a solution for the web, but in specialized domains such as video games it could have a major impact. Think of games like DotA that first came out as mods made by specialized editors instead of programming languages.
For me is a great opportunity. I'm "no code" person so I'm really happy that finally I can create website alone. Of course sometimes I have some troubles but its not something that I can't learn by reading some article or watching tutorials. So for me no code tools are big "Yes".
For now just website. But for sure I also want to try making an online portfolio. I planning to launch my own brand so I quess that I will be just keep looking for new ways of online promotion.
I think it depends on the product itself. If it is a salesy one pager then TailwindCSS has already a lot of prebuild components, if it is something really creative, like with 3d graphics or crazy font animations then you need a dev.
in an age where everything will look almost the same there will be demand to be authentic.
Right now the demand for authenticity is already high. In the future, it will be even higher. Today is not that easy to create a product that is unique. It looks the developers will be needed more for developing and improving that kind of products.
Looks like software developers will become luddites too if their job is threatened. Big portions of development not just UI development will need little to no human input after artificial general intelligence becomes common place.
Good point. But still, if that means that the profession of software developers will eventually disappear? I don't think so. Rather if they will be less needed they will have to just be more all-rounder.
Recently, I came across some stats about no-code/low-code. For example:
- Forrester, said that low-code can make software development 10-times faster than the method of writing complex code.
- On the onther hand, According to Gartner’s report, by 2024, low-code application development will be responsible for more than 65% of application development activity.
Of course, these are only predictions, we'll see if they come true...
However, in my opinion, No-Code / Low-Code tools can become invaluable support for developers, especially by eliminating simple, repetitive activities.
Thanks to them, those who know how to code will be even more valuable. Developers will focus on developing tools that require more complex skills, not provided by no-code tools
no-code is more like the past of web development. Macromedia Dreamweaver, Shockwave Flash, Frontpage, etc. And you know what, a good authoring tool unleashes more creativity than today's boilerplate SPA bullshit.
As tools evolve programmers get exponentially more productive, but they will still be coding. They might be coding different things though because what we do today can now be done by a tool
People point UI work will be replaced, I actually highly doubt that, unless there is an standardisation of UI-toolkit like we used to have in the windows 98 days (which seems incredibly unlikely). Remember Delphi and Visual Basic? Sure there was code in there, but very rarely did you need actually need to write UI-code like animating a text box around, most of it was business logic code
If anything the UI landscape is changing to be more custom for each app instead of consolidating. I expect UI coding will look very different in the future though, more focused on unique user interactions and animations instead of API calls and Form glue code