6 ms·

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 relati

by jl6 5y ago

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. Short version: use the right tool for the job.

mountainofdeath 5y ago
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.
arrayjumper 5y ago
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"
- Ensorceled 5y ago
  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.
divbzero 5y ago
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.
- jbjbjbjb 5y ago
  Seems like you either die a hero or you live long enough to see yourself become a villain.
  - darkwater 5y ago
    I don't agree: Frontpage was definitely a villain.
    - can16358p 5y ago
      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.
      - StevePerkins 5y ago
        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.
lambdasquirrel 5y ago
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.
ethbr0 5y ago
> 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.
- Tozen 5y ago
  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."
- GordonS 5y ago
  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).
  - ashtonkem 5y 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.
jimbokun 5y ago
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.
- Tozen 5y ago
  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.
- wvenable 5y ago
  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.
jrm4 5y ago
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." (Not judging here, just observing)
- Aperocky 5y ago
  > 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.
  - jrm4 5y ago
    What? I can think of a ton egregious examples of deliberate "disempowering" right off the top, to say nothing of the likely TONS more subtle ones. Shutting down Hypercard. Google Reader. Bill Gates emphasizing to NOT make MS docs compatible with others. The list goes on and on.
    - Aperocky 5y ago
      How are any of these related to making IT obsolete?
- jrochkind1 5y ago
  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.
actually_a_dog 5y ago
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.
analog31 5y ago
>>>> 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?
Waterluvian 5y ago
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.
- andyferris 5y ago
  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.)

by jl6 5y ago

mountainofdeath 5y ago

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.

arrayjumper 5y ago

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"

Ensorceled 5y ago
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.

divbzero 5y ago

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.

jbjbjbjb 5y ago
Seems like you either die a hero or you live long enough to see yourself become a villain.
- darkwater 5y ago
  I don't agree: Frontpage was definitely a villain.
  - can16358p 5y ago
    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.
    - StevePerkins 5y ago
      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.

lambdasquirrel 5y ago

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.

ethbr0 5y ago

> 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.

Tozen 5y ago
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."
GordonS 5y ago
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).
- ashtonkem 5y 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.

jimbokun 5y ago

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.

Tozen 5y ago
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.
wvenable 5y ago
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.

jrm4 5y ago

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." (Not judging here, just observing)

Aperocky 5y ago
> 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.
- jrm4 5y ago
  What? I can think of a ton egregious examples of deliberate "disempowering" right off the top, to say nothing of the likely TONS more subtle ones. Shutting down Hypercard. Google Reader. Bill Gates emphasizing to NOT make MS docs compatible with others. The list goes on and on.
  - Aperocky 5y ago
    How are any of these related to making IT obsolete?
jrochkind1 5y ago
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.

actually_a_dog 5y ago

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.

analog31 5y ago

>>>> 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?

Waterluvian 5y ago

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.

andyferris 5y ago
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.)