We're talking about creating secure enterprise apps, automating complex flows, and other tasks that would have required writing code in the past.
We're not talking about creating some silly little website with Wix.
It's not a question if this will happen, it's already happening.
If Microsoft got into this with Microsoft Power Apps, it means No Code is already mainstream, it's no longer a niche.
There's a huge demand for these tools. Companies are delivering results with these tools, without spending a fortune on R&D departments and without waiting 2 years for a product to be ready.
But don't believe me, look at the numbers:
UIPath had a revenue of $607M last year, and Google is one of their customers.
You can imagine that Google can hire all the Engineering talent that they want, and yet they picked UIPath (a no code tool) for certain processes.
At the end of the day, Google and other companies care about making as much profit as possible.
Knowing how to write code is a privilege. There are people in their 30s or 40s who didn't have the financial resources to own a computer in their teen years.
And maybe they're too busy with their current job and family and they don't have time to learn how to code, even if they would make it a priority.
And maybe those people have good ideas, and they want to start an online business, but they can't. I don't think that's fair.
As for your question, I think companies will always choose the candidate that asks for the smaller paycheck, as long as they meet the bare minimum requirements.
But it's not like they'll tell you that they picked you only because the other folks wanted more cash and more benefits.
That's available for most jobs out there, for developers and non-developers.
Some projects/tasks are more suited for no-code solutions than others. Google will never power its search engine or cloud solution with no-code tools, that's nonsense.
Also, take Postman, once you fully understand its interface, it would take 20 mins to translate that knowledge to code. The concepts around making HTTP requests are the same, no matter if you code them or select them in a list. Ultimately, the true effort is poured into learning the protocol.
You forgot to mention that a main driver behind procuring tools that allow administrators to design software procedures is that they're easier to come by and often cheaper than engineers.
If a big corporation could find enough software engineers they'd hire those rather than buy some 'no code' tool, in part because those engineers could design 'no code' or code generation tools for internal use that are exceptionally well tailored to what the company does.
I did mention in my article that big companies will push the pedal on this movement, because it will allow them to save time and money.
And most Low Code / No Code tools are affordable.
As for internal tools, it depends.
Internal tools usually have a terrible ROI (Return On Investment).
And you rarely see innovative companies building an internal tool, when there is an affordable commercial alternative.
For example, I've never heard of a company building their own internal video calling solution, even if they can do it with open source technologies such as WebRTC.
They all just prefer to use Zoom or Google Meet.
And I've never heard of an innovative company trying to build their own Email Software, they just use Microsoft Outlook.
This is also how Endtest is a game changer, companies no longer need to build their own internal overcomplicated Selenium framework.
I get a feeling you don't have much experience as a developer. Typically internal tooling isn't something that is budgeted and replacing other tasks, it's something that happens alongside main duties.
Zoom, GMeet and Outlook aren't app builder or business automation applications. In enterprise settings those tools in the Microsoft offering are quite popular, which I assume is the reason you don't mention those.
Typically Selenium is used together with tooling that records user behaviour and/or generates configuration automatically based on some data source. Could you elaborate on why you think this is "overcomplicated"?
I do have lots of experience writing code:
JavaScript, React, PHP, Python, Shell Scripts, Apple Scripts and a bit of Java.
I'd say my favourite one is Python.
But our discussion shouldn't be about what I think vs. what you think.
In the article, I'm mostly presenting the facts and the direction in which the market is moving, based on research from independent sources.
If you had news articles like this:
UIPath is closing down, because no company wants to do low-code automation
Airtable is not expanding, because companies don't want to build apps with their platform
I would have said that your opinion is correct.
If you have any data or valid resources to back up your claims, that would make the discussion more interesting.
You'd like me to explain why using Selenium leads to overcomplications?
Hi @lukeshiru, thank you for reading the entire article.
There are already tons of no code solutions being used successfully by large enterprises and small companies.
Here's a list of some of these no code tools:
Airtable
Zapier
Postman
Endtest
Bubble
UIPath
We're talking about creating secure enterprise apps, automating complex flows, and other tasks that would have required writing code in the past.
We're not talking about creating some silly little website with Wix.
It's not a question if this will happen, it's already happening.
If Microsoft got into this with Microsoft Power Apps, it means No Code is already mainstream, it's no longer a niche.
There's a huge demand for these tools. Companies are delivering results with these tools, without spending a fortune on R&D departments and without waiting 2 years for a product to be ready.
But don't believe me, look at the numbers:
UIPath had a revenue of $607M last year, and Google is one of their customers.
You can imagine that Google can hire all the Engineering talent that they want, and yet they picked UIPath (a no code tool) for certain processes.
At the end of the day, Google and other companies care about making as much profit as possible.
Knowing how to write code is a privilege. There are people in their 30s or 40s who didn't have the financial resources to own a computer in their teen years.
And maybe they're too busy with their current job and family and they don't have time to learn how to code, even if they would make it a priority.
And maybe those people have good ideas, and they want to start an online business, but they can't. I don't think that's fair.
As for your question, I think companies will always choose the candidate that asks for the smaller paycheck, as long as they meet the bare minimum requirements.
But it's not like they'll tell you that they picked you only because the other folks wanted more cash and more benefits.
That's available for most jobs out there, for developers and non-developers.
Some projects/tasks are more suited for no-code solutions than others. Google will never power its search engine or cloud solution with no-code tools, that's nonsense.
Also, take Postman, once you fully understand its interface, it would take 20 mins to translate that knowledge to code. The concepts around making HTTP requests are the same, no matter if you code them or select them in a list. Ultimately, the true effort is poured into learning the protocol.
You forgot to mention that a main driver behind procuring tools that allow administrators to design software procedures is that they're easier to come by and often cheaper than engineers.
If a big corporation could find enough software engineers they'd hire those rather than buy some 'no code' tool, in part because those engineers could design 'no code' or code generation tools for internal use that are exceptionally well tailored to what the company does.
I did mention in my article that big companies will push the pedal on this movement, because it will allow them to save time and money.
And most Low Code / No Code tools are affordable.
As for internal tools, it depends.
Internal tools usually have a terrible ROI (Return On Investment).
And you rarely see innovative companies building an internal tool, when there is an affordable commercial alternative.
For example, I've never heard of a company building their own internal video calling solution, even if they can do it with open source technologies such as WebRTC.
They all just prefer to use Zoom or Google Meet.
And I've never heard of an innovative company trying to build their own Email Software, they just use Microsoft Outlook.
This is also how Endtest is a game changer, companies no longer need to build their own internal overcomplicated Selenium framework.
I get a feeling you don't have much experience as a developer. Typically internal tooling isn't something that is budgeted and replacing other tasks, it's something that happens alongside main duties.
Zoom, GMeet and Outlook aren't app builder or business automation applications. In enterprise settings those tools in the Microsoft offering are quite popular, which I assume is the reason you don't mention those.
Typically Selenium is used together with tooling that records user behaviour and/or generates configuration automatically based on some data source. Could you elaborate on why you think this is "overcomplicated"?
Your assumption is incorrect.
I do have lots of experience writing code:
JavaScript, React, PHP, Python, Shell Scripts, Apple Scripts and a bit of Java.
I'd say my favourite one is Python.
But our discussion shouldn't be about what I think vs. what you think.
In the article, I'm mostly presenting the facts and the direction in which the market is moving, based on research from independent sources.
If you had news articles like this:
UIPath is closing down, because no company wants to do low-code automation
Airtable is not expanding, because companies don't want to build apps with their platform
I would have said that your opinion is correct.
If you have any data or valid resources to back up your claims, that would make the discussion more interesting.
You'd like me to explain why using Selenium leads to overcomplications?
I actually made a video about that last year:
youtube.com/watch?v=uJSC_YwXYZw
Junior developers worry about syntax and languages, experienced developers worry about data structures.
I'd appreciate if you linked a transcript instead.