This is an imperfect analogy, but consider for a moment the role Microsoft Excel plays.
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.
> Excel allows non-coders to do many useful things
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.
I definitely think that's a large part of it, but I saw impressive uses of Excel and Access by non-coders long before it was typical to lock-down workstations the way corporations do nowadays (like, 20 years ago).
Excel is used because it's understood by business types, not because it's the only thing available. They're comfortable with spreadsheets, it's no surprise that they'll try to solve any given problem they have with spreadsheets.
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.
That's the Venn diagram problem: how many people are there who (a) understand the needs of line of business non-developers, (b) understand their corporate IT policies that non-developers suffer under, (c) know the better way that other developers do it, & (d) are willing to wade through the political and policy @&$& to actually get something done about it?
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.
You get no argument from me, but I've seen it too frequently to believe it's not by design.
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.
Very true and a good post. Many managers and companies will go bananas if an employee wants to "program" any custom solutions for repetitive processes or for perceived efficiency. Then on the flip side, if the same employee gets "creative" with Excel, they are all for it, and smiling.
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."
It’s also useful to know some VBScript. I’m not allowed to install Python or any other “actual” programming tool on my Citrix VDI but VBScript runs fine and is pretty capable.
Excel is a great example of how “low code” or “no code” are recent buzzwords for a long continuing evolution. There have long been attempts to make software development more accessible. Some attempts stuck (Crystal Reports 1984, Excel 1987, WordPress 2003, IFTTT 2010) while others did not (HyperCard 1987, FrontPage 1995). The same will be true for the current crop of platforms.
Not as villain as Dreamweaver. Not directly but considering how MS saw that has no future and abandoned it, while Dreamweaver became the "web dev tool" for many, many out there for long years until Adobe understood those tools had no future at all.
Pfft. Dreamweaver (and even FrontPage) were perfectly fine back in the pre-IE6 days when they dominated.
People today crap on using <TABLE>'s for grid formatting, just as we crap on 1990's Java code for its `AbstractStrategyFactoryFactory` excesses. Because it's "what people did back in the bad old days", and is a glaring red flag that one's skills are out of date.
But whereas OO design patterns are a matter of subjective debate, early HTML4 and prior just flat out didn't have modern mechanism for separating presentation and content. CSS 1.x was very limited, and no major web browser even seriously supported that until the year 2000. CSS 2.x didn't get real until the 2010's.
Would any professional use Dreamweaver today? Of course not. But it was an appropriate tool for its time.
FrontPage from day one generated garbage that only IE could read, on purpose. The other day I found a notebook from my high school days in which I attached a "Best viewed in your own browser" sticker to mock the best viewed on IE (and also Netscape) buttons that were the rage back in the day (pre-2000).
I would go further and say Excel is the ultimate no-code solution. It has been used by more people to solve coding like problems by non-coders than any other no-coding tool.
I kind of disagree, because what I often see is people causing more difficulties for themselves than if they made the jump to Access, SQL, or even building an application.
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 disagree that these are coding problems. Just math isn't coding. These might be real problems that are difficult to solve, and that problem solving happens on a computer, but that doesn't make it coding.
I mostly agree. But I think there’s an important semantic distinction: people who use excel are coders. They are programming the moment they write an expression into a cell.
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.
Yeah, this is why the term "low code" seems more appriorpiate. We should definitely be describing `=A1+B1` as "code" and we should be calling it the "Excel Programming Langauge". (Especially now with LET and LAMBDA and compound data types making it Turing complete).
(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.)
It's a perfect analogy. Don't sell yourself short. Look, the following things are true.
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."
> 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."
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.
I would think the incentive to make a bazillion dollars if you did this sucessfully would outweigh your purported frequently subconscious disincentive.
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.
I'd argue there's a massive incentive to do this if you can because then every other company in the world can downsize their engineering staff and take advantage of the no code solution that you're selling. Even if you sell at an absurd price like $1M/year but it allows a company to replace 10 programmer, it'd probably be worth it.
The problem is as it's always been. Solving problems in the general sense is hard. It is true in design, it is true in AI, it is true in the automotive world, and on the battlefield. Specialized for one task is easier to learn, and easier to design for. General is harder to learn, and harder to design for.
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.
I suppose the difficult part is figuring when you've crossed the fine line from "good enough for now" to "this is becoming a monstrosity, we need to hire developers and create our own software now"
The second difficult part is when the team that built the "good enough for now" realizes that the line was crossed, that they do not have the skills to be part of the "hire developers and create our own software now" solution and then start subtly, or even openly, sabotaging every effort to move away from the Excel/VBA solution.
Case-in-point, there are more than a few non-software engineering firms where the entire business is a series of mind-boggling amalgamations of Excel and VBA with a healthy dose of Matlab on the side. I'm talking full applications written in VBA with Excel as the interface. I wouldn't be surprised to see the same in non-quant finance.
>>>> 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.
How happy was the "let's just spin up a software project" path?
There's a second version of the unhappy path, as well: you're trying to use the tool for what it's good for, but there's a bug that makes your particular use case unnecessarily difficult. At worst, what happens is you silently either get bad results or lose data. At best, you either don't use the tool for that purpose until the bug is fixed, or, you implement some silly workaround. All in all, this can be a rather disempowering situation for a non-technical user, which is the exact opposite of what "no code" promises.
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.
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.