Excel allows non-coders to do many useful things, and provides a relatively gentle on-ramp to actual code via formulas. If you take that on-ramp and keep going, towards VBA and add-ins and other pieces of Microsoft technology, you might wind up becoming a full-time software developer, leaving Excel behind and using “real” tools.
Now, there’s a happy path and an unhappy path here.
The happy path is that you use Excel for what it’s good at, but recognize when you are operating at its limits, and at that point pivot into “real” software engineering tools.
The unhappy path is that you stick with Excel too long and become mired in the world of VBA and advanced formulas and attempts at shared workbooks, and build pseudo-database application-contraptions.
No-code can be like that early Excel usage: it can grant some limited but useful powers to non-developers. But no-code can also evolve to become like those contorted, unmaintainable spreadsheet monstrosities that stretch the technology far beyond the point where some “real” software engineering would have been the right answer.
Short version: use the right tool for the job.
I heard a great quip at some point: "Why is Excel the most useful IDE?" Answer: "Because it's the one IDE every business allows every user to access."
Most of us here have forgotten that many businesses flat out ban access to programming tools for the majority of users.
And what is an enterprising user to do, when they realize they're performing the same process 100 times a day?
Reach for the only wrench they've been given access to.
PS: I guess an analogy would be people griping about shell scripting, without considering that someone might not have the ability to install their framework of choice when connecting into a client server. It gets the job done, with the tools available.
You see the same thing in reverse, with programmers reaching for Python when Excel probably would've been a better choice. Everyone reaches for what's familiar.
While it’s true for a lot of people is the only choice, there’s also an amazing amount of enterprising users that sadly don’t know any better!
In my experience, not too many. Non-developers don't know what they don't know, and developers don't know what non-developers need.
That sounds... counter productive to say the least.
We have a phrase where I work: “Security: we put the ‘no’ in ‘innovation’!”
Typically the rationale given is "Non-developers can't be trusted to write code and follow development policies," while leaving the unspoken that they're limiting development to people who by their organizational seat definition aren't experts in the problem they're being asked to code.
Problem is, Excel can be like trying to fit a square peg in a round hole, might be the wrong tool, or the less efficient option.
Nothing like watching various companies do absolute insanity and cause severe eye pain with convoluted and mangled up Excel spreadsheets. "Damn, at least go use MS Access or MS Project, if you going down this path."
There is arguably a kind of limit to how far one should take using Excel. Microsoft clearly knows this, so has Access waiting there for those that figure out they should go the next level up. Even then, Access might not be the best answer, as compared to creating an application that addresses specific needs.
I think this is important because we fool ourselves by calling these people non-coders.
Excel is really just a coding environment that has a ridiculously smooth learning curve.
(However it's still low code because all the imperative stuff about the GUI and loading/saving files and updating other cells reactively and so-on is written for you by Microsoft.)
1) This industry absolutely has the capability create more tools like Excel that are both extremely empowering and orders of magnitude easier than what we think of as coding.
2) Unfortunately, there's a strong, likely frequently subconscious, incentive to definitely not do this, since it carries a strong danger of IT making itself "obsolete."
(Not judging here, just observing)
I can't think of a single case that this has ever been the decision making process when creating a product.
If you look at the myriad of available tools that trends in this direction, in all fields, you'll realize that the industry is littered with both successful and failed examples, ERP systems alone are a huge market.
It's just that people wanted to replace actual convoluted general purpose logic known as coding, that they ran into problem that could not be addressed by some GUI. And that no-code solutions that exist today propagandize about.
Shutting down Hypercard.
Google Reader.
Bill Gates emphasizing to NOT make MS docs compatible with others. The list goes on and on.
Plus there are other people in this comments thread saying they are working for companies that are (they claim) doing so. Not to mention all the past attempts to do so over the past 40 years. Is the idea that those companies are intentionally not doing it as well as they could, because of their allegience to not making the field of IT obsolete?
The idea that we collectively could easily be making software construction toolkits for non-programmers that would make "IT obsolete", it's an easy problem, but we just choose not to... is a conspiracy theory.
With that in mind, it's interesting that we still even have "general-purpose programming languages." There is some specialization for sure, but that's partly because of things like e.g. the browser only supports Javascript. And then you see things going back the other way, e.g. with NodeJS.
So I'd wait till we see some actual, real specialization in the languages / tools that engineers use, beyond "ecosystem" reasons. In the meantime, we've seen tools that help non-programmers "automate" things. Everything from CAD to Wix, Salesforce, Figma, etc. would fall under that umbrella. But then you still have code. If what you want is automation / labor-force-multipliers, the common denominator will still be highly generalized, and therefore, hard.
How happy was the "let's just spin up a software project" path?
TL;DR: "no code" is just somebody else's code. You're introducing a massive external dependency you have little control over by using a "no code" solution.
