12 ms·

After seeing the no-code movement over and over again, I do not believe that this time it is any different. From MS Access days, Adobe's Dreamweaver, and many o

After seeing the no-code movement over and over again, I do not believe that this time it is any different. From MS Access days, Adobe's Dreamweaver, and many other forms of no-code solutions, the environment that supports no-code requires a tremendous amount of code. Knowing how to code can help you optimize, automate, configure no-code solutions. The end result is always back to code.

waynecochran 6y ago
It turns out that language is an amazingly powerful way to describe solutions to problems. Nothing really better has come along.
- asdfman123 6y ago
  Software engineers spend every day trying to automate away their jobs, and it's hardly a conservative field. If it were easier to use a visual interface than code, then devs would figure it out and we'd all start doing it. The "no code" revolution is probably more accurately the Microsoft Access replacement for our generation. Sleeker, cooler, more professional. But like Access, you have to replace it with real software when it starts getting complex.
- paulgb 6y ago
  I think this is just it: text has a higher information density than (say) visual programming tools. At some point you quickly reach an amount of threshold of complexity where you either need to: 1. Hide parts of the program (e.g. hidden cells on a spreadsheet; attributes of nodes in a visual programming environment) 2. Switch to text for the higher information density. I think the burden of #1 quickly surpasses the burden of learning to work with #2.
asdfman123 6y ago
No code can be great if you want to spin up something simple quickly. Once it grows to any reasonable level of complexity it becomes more of a hindrance than a help. Access was actually a great tool for allowing semi-technical people make quick apps, but almost every shop I've been in has needed to convert Access to grown-up software.
- tabtab 6y ago
  Granted, it's a good way to prototype ideas. Less analysis is needed when one converts from Access to the new thing because the ideas are road tested. But one problem is that modern web stacks are a bloated incoherent mess that take an army of specialists to manage. That may be part of the reason for the resurgence of "no code" tools. But the real fix is to simplify web stacks for smaller projects. We don't need Rube Goldberg routing engines/URL-prettifiers, ORM organics, Bootcrap organics (UI), Async/Await bloat, etc. We want our app track some local e-paper-work, not be Netflix. A Learjet will do, don't gear it for Jumbo Jets. Time for a KISS web stack to become a de-facto standard.
  - asdfman123 6y ago
    Oh yeah, Access was great for prototyping and I've argued as much here several times. I've built Access prototypes in earlier jobs. > But the real fix is to simplify web stacks for smaller projects We've already done that. RoR, Django, ASP.NET MVC, etc. etc. It's super easy to get something working out of the box. But at some point, you still need to understand what your database is doing and optimize for it. Some level of complexity is inescapable. And you could probably argue that as back-end has gotten simpler, complexity has just expanded to fill the void. Now we expect fancy JS interfaces on top of them, too. And phone apps. I have no doubt all of the things I mentioned will get simpler, but I can't foresee anything that will make software devs irrelevant in on the immediate horizon. I suppose at some point BAs/PMs (people who gather requirements and draw wireframes) will be able to write code, and we'll start to compete more with skilled BAs. But that's still not the end of the entire profession. Gathering requirements is still hard.
- monksy 6y ago
  Same can be said for Python, VB, and VBA.
- tootie 6y ago
  A lot never will though. I don't see no-code replacing many custom developed applications. It see it making apps accessible for processes that used to managed by spreadsheet and email.
ageyfman 6y ago
these companies only need to move the needle a little bit to be wildly successful and usher a new set of internal applications that end-users can put together. Will it be children programming our internal enterprise apps? Maybe not. But there are a whole lot of folks who have the need and the desire to get some internal things built, and with these new tools (retool especially), it's not that hard. Calling it no-code does these tools a disservice. It's really block-oriented programming with a variety of complex blocks.
NortySpock 6y ago
My experience with SSIS 2012, Microsoft's low-code ETL tool, suggests that you're trading code for a giant config file. Unless carefully planned out to be modular, you end up with a giant pile of technical debt that is (a) pretty opaque in its error messages (b) has poor error handling systems (c) is brittle in its ability to handle changing file formats or business needs (d) can only be tested end-to-end, with no space for small unit tests to act as guide rails (e) makes it very easy to hide business logic all throughout the ETL process Upside to this tool: It seems to be handling a lot of simple parallelization speedups behind the scenes for you, and catches most type-conversion errors.
- commandlinefan 6y ago
  > a giant config file Which, inevitably, starts to include things like macros, include files, looping constructs and eventually bits of perl or TCL.
  - TeMPOraL 6y ago
    Or more typically, a half-baked Lisp that uses XML or JSON instead of s-expressions. Code is data, but the converse of that is that a sufficiently complex configuration file is just a piece of executable code.
- seabrookmx 6y ago
  See also: Pentaho and it's associated tooling, as well as many "workflow management" tools like Camunda. I'd stay as far away from all of these tools as possible.
swyx 6y ago
the reality is that even the no-code advocates are fully aware of this. I was surprised that webflow let me publish "No code is a lie" on their blog. https://webflow.com/blog/no-code-is-a-lie https://webflow.com/blog/no-code-is-a-lie if you stop there though, you're missing out on the business opportunity. you can dunk on things on HN all you want but if these businesses are right and the demand for software has massively outstripped the availability of engineers then you're gonna make money in no code tools.
lucasverra 6y ago
Don't get me wrong, I'm 100% agreeing with you. However, I can personally vouch for 2 champions in no code. The big behemoth is Salesforce.com. The incipient champion is Bubble.io. Cloud infrastructure ,API consumption and mobile usage are the paradigm shifting variables that were not present 10y ago. The fact that cloud is getting (traditional) corporate green lights and that every employee is using software to do regular 9-5 work indicates that software creation is demanded at exponential scale. > The end result is always back to code. Sure. The same way the end result is always back to electrons flowing around. The abstraction layer that no code provides NOT TO YOU but to Michel the accountant is very relevant and will (10y from now) produce a new paradigm shift, as Salesforce pioneered the "no software" [1] SaaS 20y ago. And the paradigm shift is not "0 code". It's "0 code to get thing rolling; and developing programming skills visually to later on have a more productive talk with coders" [1] https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2Fmind-force.de%2Ffiles%2F2015%2F03%2Fsalesforce-nosoftware.jpg&f=1&nofb=1 https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2F...
- reaperducer 6y ago
  The big behemoth is Salesforce.com My experience has been different. When I worked for a travel company, it joined Salesforce. Shortly thereafter it had to hire a full-time Apex programmer to make Salesforce do all the things the Salesforce salespeople promised it would do without a programmer.
  - drcongo 6y ago
    Exactly this. I've never seen anyone set up Salesforce themselves, I'd even go so far as to suggest that Salesforce is wilfully so opaque purely to enable a commercial ecosystem of "certified" chancers and ne'er-do-wells who you have to call every time anything goes wrong.
- Kalium 6y ago
  > The big behemoth is Salesforce.com. My experience with Salesforce.com is that it's only a no-code champion if your needs are so simple that you might as well not be using Salesforce.com - i.e., a simple CRM with a few plugins. The real strength of Salesforce.com is that you can use code to customize it and get the real utility you're paying for out of it. It's "no software" in the sense that all SaaS systems are "no software". Realistically, Salesforce.com is very much enterprise software of the sort that requires real customization in the form of real code to implement the important business requirements.
icoder 6y ago
I've been using Mendix for a while now (for a client), which is more low-code than no-code. I enjoy it quite a bit. It's very easy to add a new entity (table) and some screens for CRUD stuff. Even without code you can customise quite a bit, but there's always Java (server) and JavaScript (client) actions. Nevertheless, as with many frameworks, it gets awkward when you move too far away from the 'intended use cases'. However, I do think that you still need a dev mindset, with dev experience, to use it well. Principles like DRY, loose coupling, code organisation, consistent and informative naming, concise logic, etc adhere just as well. Those hard to transfer skills you build up over time. Although a junior may get things working very quickly, keeping things maintainable and extendable is just as hard, or even harder.
- tluyben2 6y ago
  Mendix & Outsystems are pretty popular in the enterprise space and they work quite well. Like you say, don't move too far away from the intended space, but the LoB (line of business) space is vast for big enterprises and that's what these tools are for. There is no need to do 100% as you can get to 80-90% and the rest you don't do with those packages; you do with code. Why is that a problem; you use different frameworks / languages / dbs / etc with code too; these systems are no different; use them what they are meant for and do the rest with other tools. Ofcourse there is more than enough work to be had just creating departmental LoB apps to last you 1000s of lifetimes, but that's another story. So like you said; I believe you still need to be a dev to deliver with these systems; 'end user programming' is not close outside Excel. People who know nothing about programming will generally make complete monsters with these systems, even after training (I saw it a lot with Outsystems when I click open a business flow). Real enduser development revolutions we won't see this low-code wave, maybe the next somewhere around 2030?
- vram22 6y ago
  > Nevertheless, as with many frameworks, it gets awkward when you move too far away from the 'intended use cases' Right. And that probably applies to many, if not all frameworks, by virtue (vice?) of their design. I don't know Mendix, but I've worked on programming frameworks like Rails, Flask and others, including some in-house company proprietary ones. You sometimes have to work around their limitations with custom code, awkwardly, even Rube Goldberg style at times. And there can be instances or even categories of apps that can't be done using the framework at all. The framework giveth and the framework taketh away.
reaperducer 6y ago
I agree. This goes back even further than that. In the 80's various "construction set" programs were all the rage. They were essentially no-code programs, many disguised as games. Later there were 16-bit solutions, like a program called "Can Do" for the Amiga. (I'm not entirely sure of the title, but I remember the splash screen had a voice shouting "I Can Do; you can, too!") Macromedia Dreamweaver was the big inflection point because the results could be deployed on the web, for anyone to see, regardless of what box they were running. The problem I have is that it devalues the worth of actual programmers by making everyone think what we do is easy. It isn't. I see this all the time with do-gooder charities on TV "We're teaching kids to code, and next week they'll all be billionaires!" The present themselves as if a week in a makeshift classroom is all it takes to compile and deploy a Swift app. I've thought about this since the early part of this year when a middle manager in my company's Communications department dismissively told me that she could do my job because, "I know code." What does that even mean?
- brlewis 6y ago
  > We're teaching kids to code, and next week they'll all be billionaires! Sure, that's not true. But they will gain a better understanding of how to organize and process information. This understanding will help them even if they don't end up in a software engineering career.
  - 908B64B197 6y ago
    But think of all the social networks they could launch!
- 908B64B197 6y ago
  > I've thought about this since the early part of this year when a middle manager in my company's Communications department dismissively told me that she could do my job because, "I know code." What does that even mean? It's a signal to look for a better position somewhere else. Sounds like you work at a company that considers tech to be "the easy part" or a cost center...
- jonathanlydall 6y ago
darepublic 6y ago
I'm trying to think of a historical analog.. something that was always on the cusp of discovery and often hyped up but either never realized or only realized after many many delays. My partially educated mind thinks of two things -- alchemy and the philosopher's stone -- and flight.
- karmakaze 6y ago
  My historical analogue is the telephone. Adoption and the number of switchboard operators was growing so fast that it was said that at that rate everyone would have to be an operator. Then direct-dialing became a thing that replaced switchboards. If software continues to eat the world, no-code/low-code a matter of when, not if.
- ByteJockey 6y ago
  Fusion?
andreilys 6y ago
David Parnas in 1985: Throughout my career in computing I have heard people claim that the solution to the software problem is automatic programming. All that one has to do is write the specifications for the software, and the computer will find a program [...] The oldest paper known to me that discusses automatic programming was written in the 1940s by Saul Gorn when he was working at the Aberdeen Proving Ground. This paper, entitled “Is Automatic Programming Feasible?” was classified for a while. It answered the question positively. At that time, programs were fed into computers on paper tapes. The programmer worked the punch directly and actually looked at the holes in the tape. I have seen programmers “patch” programs by literally patching the paper tape. The automatic programming system considered by Gorn in that paper was an assembler in today’s terminology. All that one would have to do with his automatic programming system would be to write a code such as CLA, and the computer would automatically punch the proper holes in the tape. In this way, the programmer’s task would be performed automatically by the computer. In later years the phrase was used to refer to program generation from languages such as IT, FORTRAN, and ALGOL. In each case, the programmer entered a specification of what he wanted, and the computer produced the program in the language of the machine. In short, automatic programming always has been a euphemism for programming with a higher-level language than was then available to the programmer. Research in automatic programming is simply research in the implementation of higher-level programming languages. http://web.stanford.edu/class/cs99r/readings/parnas1.pdf http://web.stanford.edu/class/cs99r/readings/parnas1.pdf
- commandlinefan 6y ago
  > automatic programming always has been a euphemism for programming with a higher-level language than was then available to the programmer And it seems to me that progress is going in the opposite direction than "they" want. Every time you move up the abstraction stack, you're surrendering some decision-making to the lower levels. If the underlying technologies guess right every time, you have no need to understand what they're doing. The first time they guess wrong, you have to spend a lot of time understanding not only how the lower layers work, and not only why they did the "wrong" thing in this one instance, but how to fiddle correctly with the layer you're operating at to get the lower layers to behave properly. You can work quickly with the high-level abstractions only as long as you understand the lower levels reasonably well. Optimal machine learning requires a good understanding of memory cache hierarchies, parallel instructions and complexity theory - not to mention the statistics and calculus that it's formed on. And "optimal" isn't some trivial "save a few seconds" but often "return an answer within the lifetime of the universe".
outworlder 6y ago
> knowing how to code can help you optimize, automate, configure no-code solutions. The end result is always back to code. There's some value in having abstractions being more visible. I don't think that strictly speaking something like Node-Red qualifies as 'no code'. But it made me understand that, given that so much of development nowadays consists of 'gluing' code together, there's potential for such tools. Even if some of the boxes happen to allow you to write code. At some point, all you care about is inputs and outputs. We are missing a better way to do these things.
Icedcool 6y ago
Notepad is still my favorite website design app.
specialist 6y ago
"The end result is always back to code." Yes, and: you understate the downside. While No Code (nee Visual Programming, CASE Tools, whatever) may handle 90% of the use cases, the remaining 10% become dramatically harder. Because now you're fighting the framework. Which is an angry 800lb gorilla sitting between you and your work. Faced with the same challenge, I went in the opposite direction. Typical strategy of BizTalk, Talend, SeeBeyond, many many others is some kind of patch cord flow chart style programming, with Access VBA style event hooks for script extensions. I created a stupid simple framework and API optimized for our domain (medical records). Think serverless computing and awesome DOMs for HL7 and adjacent data formats. Onboarding for our SeeBeyond-based projects was 3 to 6 months. Using my stack was 1 to 2 weeks. (One of the weeks was teaching healthcare domain experts some Java, Eclipse IDE, and version control.) Further, in my experience, none of these No Code solutions have useful exception handling, logging, fault/error recovery, and other misc devops type stuff. So are an absolute nightmare to support in production.
- gbourne 6y ago
  The remaining 10% become dramatically harder. Because now you're fighting the framework. That is a great point. Whenever I've tried a no-code solution I end up dropping it and going back to code. Some insurmountable roadblock appears that if I had started with code I won't be in this mess. I've also made the mistake of recommending no-code solutions to my business - trying to reach for the golden ring of self-sufficiency. Seems great at first and then you end up trying to "debug" a no-code framework that you have little of no insight into.
a_c 6y ago
People would rather learn "no code" than to learn actual code. But guess what.."no code" IS code. It's turtle all the way down.
- benjaminjosephw 6y ago
  People would rather learn [high-level abstraction] than to learn [low-level abstraction]. But guess what..[high-level abstraction] IS [a kind of abstraction]. This is true for all of us - it's just that the level of abstraction each of us is comfortable with is different. Not sure why people don't understand the value of raising the level of abstraction for more people to participate in software creation. It seems like an obviously valuable and worthwhile objective, even if it does look different to the way I build software.
  - TheOperator 6y ago
    Because they're pretending that this next [high-level abstraction] will be replaced by another style of [high-level abstraction] as if [high-level abstraction] is nothing but a scaffold to let us ascend to the true productive glory of [high-level abstraction]. It ignores the fact that it's not unheard of for platforms which started out no-code later REGRESS and introduce coding features such as APIs because as it turns out, no-code is intrinsically limited in a lot of very significant ways. When I use a "no-code" product it's usually not more than a few months before I start using it's API and adding small bits of code here and there to do things not natively supported by the product. You would have to have a puritanical fervor and a lack of sense to want to eliminate all semblance of code from a product made out of code. It's almost as if after seeing you could add images to Microsoft word documents you saw an article coming out about how Written English was going to be replaced by Hieroglyphics and soon we could communicate with nothing but Emoji and talking about how the next generation won't be literate. The sentiment in this thread is mostly a reaction to irritating and implausible clickbait.
    - michaelmrose 6y ago
      Well put especially the last bit.
lordnacho 6y ago
I get this hunch that no-code is attractive because it hides the true costs. You can apparently hire cheaper labor, but you don't see the maintenance costs. You can also apparently delegate coding tasks to non-coders, which might help you squeeze the budget bubble around the business. But there's costs to that as well in terms of making people less effective at their normal work.
TheOperator 6y ago
A third of the websites in the world use wordpress which can certainly be configured using "no-code" and yet it's being sold as something brand new. Excel is everywhere and allows for "no-code" automation. No-code has been around forever and for some reason incremental improvements to something utterly pervasive is a revolution that will be embraced by the next generation. All I can think of is how Windows used to be administered almost entirely through the GUI but eventually PowerShell was invented and its popularity grows year over year. How is that even possible when the "no-code" way to administer Windows must clearly be better and more accessible and user friendly and coding is old fashioned and borderline obsolete? Every company with their heads on straight would fire anybody who uses PowerShell and replace all their admins with unskilled high school graduates. There is not enough room in town for both no-code and code solutions, so I expect Microsoft to remove PowerShell in it's next update.
msla 6y ago
"No code" as a term sounds like "serverless": There's a blatant contradiction in the terminology, but if you point it out, people begin to snicker up their sleeves at the person who reads the words as if they were English. There's definitely a place for a la carte pricing for server-based software ("serverless" which of course includes servers, you silly person) and there's a place for very high-level code in domain-specific languages to solve immediate business problems ("no code" which of course includes writing code, you silly person) so just learn the shibboleth and try to avoid sounding silly. /s
vram22 6y ago
> and many other forms of no-code solutions Yes. Also CASE tools, those with a code generation feature. https://en.m.wikipedia.org/wiki/Computer-aided_software_engineering https://en.m.wikipedia.org/wiki/Computer-aided_software_engi...
- vram22 6y ago
  > with a code generation feature Pun unintended :)
skohan 6y ago
I think the core of the issue is that real problems contain a lot of complexity, and code is still by far the most efficient way to encode complex logic. For instance, I've done some work with node-based editors like Node Red and Max MXP, and while they are nice for simple cases, invariably they reach a tipping point where you end up with a giant graph which is far less navigable and comprehensible than a set of source files. There's no escaping complexity.
fastball 6y ago
Agreed. No-code is only long-term viable once no-code tooling is self-hosted.
sidpatil 6y ago
" When someone says 'I want a programming language in which I need only say what I wish done,' give him a lollipop." Epigram 93, Alan Perlis http://www.cs.yale.edu/homes/perlis-alan/quotes.html http://www.cs.yale.edu/homes/perlis-alan/quotes.html
paulmendoza 6y ago
It is different this time. I am a really good coder but I am using no code tools as much as I can. I only use code for new projects if I absolutely must.
divbzero 6y ago
I share your view that the limits of no-code have been proven time and time again. Just ask the countless devs who have added custom code to WordPress or Squarespace sites. That said, maybe this time is (a bit) different. Machine learning is markedly more mature today and could take no-code farther than it has in the past.
- Ma8ee 6y ago
  How would machine learning help?

waynecochran 6y ago

It turns out that language is an amazingly powerful way to describe solutions to problems. Nothing really better has come along.

asdfman123 6y ago
Software engineers spend every day trying to automate away their jobs, and it's hardly a conservative field. If it were easier to use a visual interface than code, then devs would figure it out and we'd all start doing it. The "no code" revolution is probably more accurately the Microsoft Access replacement for our generation. Sleeker, cooler, more professional. But like Access, you have to replace it with real software when it starts getting complex.
paulgb 6y ago
I think this is just it: text has a higher information density than (say) visual programming tools. At some point you quickly reach an amount of threshold of complexity where you either need to: 1. Hide parts of the program (e.g. hidden cells on a spreadsheet; attributes of nodes in a visual programming environment) 2. Switch to text for the higher information density. I think the burden of #1 quickly surpasses the burden of learning to work with #2.

asdfman123 6y ago

No code can be great if you want to spin up something simple quickly. Once it grows to any reasonable level of complexity it becomes more of a hindrance than a help. Access was actually a great tool for allowing semi-technical people make quick apps, but almost every shop I've been in has needed to convert Access to grown-up software.

tabtab 6y ago
Granted, it's a good way to prototype ideas. Less analysis is needed when one converts from Access to the new thing because the ideas are road tested. But one problem is that modern web stacks are a bloated incoherent mess that take an army of specialists to manage. That may be part of the reason for the resurgence of "no code" tools. But the real fix is to simplify web stacks for smaller projects. We don't need Rube Goldberg routing engines/URL-prettifiers, ORM organics, Bootcrap organics (UI), Async/Await bloat, etc. We want our app track some local e-paper-work, not be Netflix. A Learjet will do, don't gear it for Jumbo Jets. Time for a KISS web stack to become a de-facto standard.
- asdfman123 6y ago
  Oh yeah, Access was great for prototyping and I've argued as much here several times. I've built Access prototypes in earlier jobs. > But the real fix is to simplify web stacks for smaller projects We've already done that. RoR, Django, ASP.NET MVC, etc. etc. It's super easy to get something working out of the box. But at some point, you still need to understand what your database is doing and optimize for it. Some level of complexity is inescapable. And you could probably argue that as back-end has gotten simpler, complexity has just expanded to fill the void. Now we expect fancy JS interfaces on top of them, too. And phone apps. I have no doubt all of the things I mentioned will get simpler, but I can't foresee anything that will make software devs irrelevant in on the immediate horizon. I suppose at some point BAs/PMs (people who gather requirements and draw wireframes) will be able to write code, and we'll start to compete more with skilled BAs. But that's still not the end of the entire profession. Gathering requirements is still hard.
monksy 6y ago
Same can be said for Python, VB, and VBA.
tootie 6y ago
A lot never will though. I don't see no-code replacing many custom developed applications. It see it making apps accessible for processes that used to managed by spreadsheet and email.

ageyfman 6y ago

these companies only need to move the needle a little bit to be wildly successful and usher a new set of internal applications that end-users can put together. Will it be children programming our internal enterprise apps? Maybe not. But there are a whole lot of folks who have the need and the desire to get some internal things built, and with these new tools (retool especially), it's not that hard. Calling it no-code does these tools a disservice. It's really block-oriented programming with a variety of complex blocks.

NortySpock 6y ago

My experience with SSIS 2012, Microsoft's low-code ETL tool, suggests that you're trading code for a giant config file. Unless carefully planned out to be modular, you end up with a giant pile of technical debt that is (a) pretty opaque in its error messages (b) has poor error handling systems (c) is brittle in its ability to handle changing file formats or business needs (d) can only be tested end-to-end, with no space for small unit tests to act as guide rails (e) makes it very easy to hide business logic all throughout the ETL process Upside to this tool: It seems to be handling a lot of simple parallelization speedups behind the scenes for you, and catches most type-conversion errors.

commandlinefan 6y ago
> a giant config file Which, inevitably, starts to include things like macros, include files, looping constructs and eventually bits of perl or TCL.
- TeMPOraL 6y ago
  Or more typically, a half-baked Lisp that uses XML or JSON instead of s-expressions. Code is data, but the converse of that is that a sufficiently complex configuration file is just a piece of executable code.
seabrookmx 6y ago
See also: Pentaho and it's associated tooling, as well as many "workflow management" tools like Camunda. I'd stay as far away from all of these tools as possible.

swyx 6y ago

the reality is that even the no-code advocates are fully aware of this. I was surprised that webflow let me publish "No code is a lie" on their blog. https://webflow.com/blog/no-code-is-a-lie https://webflow.com/blog/no-code-is-a-lie if you stop there though, you're missing out on the business opportunity. you can dunk on things on HN all you want but if these businesses are right and the demand for software has massively outstripped the availability of engineers then you're gonna make money in no code tools.

lucasverra 6y ago

Don't get me wrong, I'm 100% agreeing with you. However, I can personally vouch for 2 champions in no code. The big behemoth is Salesforce.com. The incipient champion is Bubble.io. Cloud infrastructure ,API consumption and mobile usage are the paradigm shifting variables that were not present 10y ago. The fact that cloud is getting (traditional) corporate green lights and that every employee is using software to do regular 9-5 work indicates that software creation is demanded at exponential scale. > The end result is always back to code. Sure. The same way the end result is always back to electrons flowing around. The abstraction layer that no code provides NOT TO YOU but to Michel the accountant is very relevant and will (10y from now) produce a new paradigm shift, as Salesforce pioneered the "no software" [1] SaaS 20y ago. And the paradigm shift is not "0 code". It's "0 code to get thing rolling; and developing programming skills visually to later on have a more productive talk with coders" [1] https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2Fmind-force.de%2Ffiles%2F2015%2F03%2Fsalesforce-nosoftware.jpg&f=1&nofb=1 https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2F...

reaperducer 6y ago
The big behemoth is Salesforce.com My experience has been different. When I worked for a travel company, it joined Salesforce. Shortly thereafter it had to hire a full-time Apex programmer to make Salesforce do all the things the Salesforce salespeople promised it would do without a programmer.
- drcongo 6y ago
  Exactly this. I've never seen anyone set up Salesforce themselves, I'd even go so far as to suggest that Salesforce is wilfully so opaque purely to enable a commercial ecosystem of "certified" chancers and ne'er-do-wells who you have to call every time anything goes wrong.
Kalium 6y ago
> The big behemoth is Salesforce.com. My experience with Salesforce.com is that it's only a no-code champion if your needs are so simple that you might as well not be using Salesforce.com - i.e., a simple CRM with a few plugins. The real strength of Salesforce.com is that you can use code to customize it and get the real utility you're paying for out of it. It's "no software" in the sense that all SaaS systems are "no software". Realistically, Salesforce.com is very much enterprise software of the sort that requires real customization in the form of real code to implement the important business requirements.

icoder 6y ago

I've been using Mendix for a while now (for a client), which is more low-code than no-code. I enjoy it quite a bit. It's very easy to add a new entity (table) and some screens for CRUD stuff. Even without code you can customise quite a bit, but there's always Java (server) and JavaScript (client) actions. Nevertheless, as with many frameworks, it gets awkward when you move too far away from the 'intended use cases'. However, I do think that you still need a dev mindset, with dev experience, to use it well. Principles like DRY, loose coupling, code organisation, consistent and informative naming, concise logic, etc adhere just as well. Those hard to transfer skills you build up over time. Although a junior may get things working very quickly, keeping things maintainable and extendable is just as hard, or even harder.

tluyben2 6y ago
Mendix & Outsystems are pretty popular in the enterprise space and they work quite well. Like you say, don't move too far away from the intended space, but the LoB (line of business) space is vast for big enterprises and that's what these tools are for. There is no need to do 100% as you can get to 80-90% and the rest you don't do with those packages; you do with code. Why is that a problem; you use different frameworks / languages / dbs / etc with code too; these systems are no different; use them what they are meant for and do the rest with other tools. Ofcourse there is more than enough work to be had just creating departmental LoB apps to last you 1000s of lifetimes, but that's another story. So like you said; I believe you still need to be a dev to deliver with these systems; 'end user programming' is not close outside Excel. People who know nothing about programming will generally make complete monsters with these systems, even after training (I saw it a lot with Outsystems when I click open a business flow). Real enduser development revolutions we won't see this low-code wave, maybe the next somewhere around 2030?
vram22 6y ago
> Nevertheless, as with many frameworks, it gets awkward when you move too far away from the 'intended use cases' Right. And that probably applies to many, if not all frameworks, by virtue (vice?) of their design. I don't know Mendix, but I've worked on programming frameworks like Rails, Flask and others, including some in-house company proprietary ones. You sometimes have to work around their limitations with custom code, awkwardly, even Rube Goldberg style at times. And there can be instances or even categories of apps that can't be done using the framework at all. The framework giveth and the framework taketh away.

reaperducer 6y ago

I agree. This goes back even further than that. In the 80's various "construction set" programs were all the rage. They were essentially no-code programs, many disguised as games. Later there were 16-bit solutions, like a program called "Can Do" for the Amiga. (I'm not entirely sure of the title, but I remember the splash screen had a voice shouting "I Can Do; you can, too!") Macromedia Dreamweaver was the big inflection point because the results could be deployed on the web, for anyone to see, regardless of what box they were running. The problem I have is that it devalues the worth of actual programmers by making everyone think what we do is easy. It isn't. I see this all the time with do-gooder charities on TV "We're teaching kids to code, and next week they'll all be billionaires!" The present themselves as if a week in a makeshift classroom is all it takes to compile and deploy a Swift app. I've thought about this since the early part of this year when a middle manager in my company's Communications department dismissively told me that she could do my job because, "I know code." What does that even mean?

brlewis 6y ago
> We're teaching kids to code, and next week they'll all be billionaires! Sure, that's not true. But they will gain a better understanding of how to organize and process information. This understanding will help them even if they don't end up in a software engineering career.
- 908B64B197 6y ago
  But think of all the social networks they could launch!
908B64B197 6y ago
> I've thought about this since the early part of this year when a middle manager in my company's Communications department dismissively told me that she could do my job because, "I know code." What does that even mean? It's a signal to look for a better position somewhere else. Sounds like you work at a company that considers tech to be "the easy part" or a cost center...
jonathanlydall 6y ago

darepublic 6y ago

I'm trying to think of a historical analog.. something that was always on the cusp of discovery and often hyped up but either never realized or only realized after many many delays. My partially educated mind thinks of two things -- alchemy and the philosopher's stone -- and flight.

karmakaze 6y ago
My historical analogue is the telephone. Adoption and the number of switchboard operators was growing so fast that it was said that at that rate everyone would have to be an operator. Then direct-dialing became a thing that replaced switchboards. If software continues to eat the world, no-code/low-code a matter of when, not if.
ByteJockey 6y ago
Fusion?

andreilys 6y ago

David Parnas in 1985: Throughout my career in computing I have heard people claim that the solution to the software problem is automatic programming. All that one has to do is write the specifications for the software, and the computer will find a program [...] The oldest paper known to me that discusses automatic programming was written in the 1940s by Saul Gorn when he was working at the Aberdeen Proving Ground. This paper, entitled “Is Automatic Programming Feasible?” was classified for a while. It answered the question positively. At that time, programs were fed into computers on paper tapes. The programmer worked the punch directly and actually looked at the holes in the tape. I have seen programmers “patch” programs by literally patching the paper tape. The automatic programming system considered by Gorn in that paper was an assembler in today’s terminology. All that one would have to do with his automatic programming system would be to write a code such as CLA, and the computer would automatically punch the proper holes in the tape. In this way, the programmer’s task would be performed automatically by the computer. In later years the phrase was used to refer to program generation from languages such as IT, FORTRAN, and ALGOL. In each case, the programmer entered a specification of what he wanted, and the computer produced the program in the language of the machine. In short, automatic programming always has been a euphemism for programming with a higher-level language than was then available to the programmer. Research in automatic programming is simply research in the implementation of higher-level programming languages. http://web.stanford.edu/class/cs99r/readings/parnas1.pdf http://web.stanford.edu/class/cs99r/readings/parnas1.pdf

commandlinefan 6y ago
> automatic programming always has been a euphemism for programming with a higher-level language than was then available to the programmer And it seems to me that progress is going in the opposite direction than "they" want. Every time you move up the abstraction stack, you're surrendering some decision-making to the lower levels. If the underlying technologies guess right every time, you have no need to understand what they're doing. The first time they guess wrong, you have to spend a lot of time understanding not only how the lower layers work, and not only why they did the "wrong" thing in this one instance, but how to fiddle correctly with the layer you're operating at to get the lower layers to behave properly. You can work quickly with the high-level abstractions only as long as you understand the lower levels reasonably well. Optimal machine learning requires a good understanding of memory cache hierarchies, parallel instructions and complexity theory - not to mention the statistics and calculus that it's formed on. And "optimal" isn't some trivial "save a few seconds" but often "return an answer within the lifetime of the universe".

outworlder 6y ago

> knowing how to code can help you optimize, automate, configure no-code solutions. The end result is always back to code. There's some value in having abstractions being more visible. I don't think that strictly speaking something like Node-Red qualifies as 'no code'. But it made me understand that, given that so much of development nowadays consists of 'gluing' code together, there's potential for such tools. Even if some of the boxes happen to allow you to write code. At some point, all you care about is inputs and outputs. We are missing a better way to do these things.

Icedcool 6y ago

Notepad is still my favorite website design app.

specialist 6y ago

"The end result is always back to code." Yes, and: you understate the downside. While No Code (nee Visual Programming, CASE Tools, whatever) may handle 90% of the use cases, the remaining 10% become dramatically harder. Because now you're fighting the framework. Which is an angry 800lb gorilla sitting between you and your work. Faced with the same challenge, I went in the opposite direction. Typical strategy of BizTalk, Talend, SeeBeyond, many many others is some kind of patch cord flow chart style programming, with Access VBA style event hooks for script extensions. I created a stupid simple framework and API optimized for our domain (medical records). Think serverless computing and awesome DOMs for HL7 and adjacent data formats. Onboarding for our SeeBeyond-based projects was 3 to 6 months. Using my stack was 1 to 2 weeks. (One of the weeks was teaching healthcare domain experts some Java, Eclipse IDE, and version control.) Further, in my experience, none of these No Code solutions have useful exception handling, logging, fault/error recovery, and other misc devops type stuff. So are an absolute nightmare to support in production.

gbourne 6y ago
The remaining 10% become dramatically harder. Because now you're fighting the framework. That is a great point. Whenever I've tried a no-code solution I end up dropping it and going back to code. Some insurmountable roadblock appears that if I had started with code I won't be in this mess. I've also made the mistake of recommending no-code solutions to my business - trying to reach for the golden ring of self-sufficiency. Seems great at first and then you end up trying to "debug" a no-code framework that you have little of no insight into.

a_c 6y ago

People would rather learn "no code" than to learn actual code. But guess what.."no code" IS code. It's turtle all the way down.

benjaminjosephw 6y ago
People would rather learn [high-level abstraction] than to learn [low-level abstraction]. But guess what..[high-level abstraction] IS [a kind of abstraction]. This is true for all of us - it's just that the level of abstraction each of us is comfortable with is different. Not sure why people don't understand the value of raising the level of abstraction for more people to participate in software creation. It seems like an obviously valuable and worthwhile objective, even if it does look different to the way I build software.
- TheOperator 6y ago
  Because they're pretending that this next [high-level abstraction] will be replaced by another style of [high-level abstraction] as if [high-level abstraction] is nothing but a scaffold to let us ascend to the true productive glory of [high-level abstraction]. It ignores the fact that it's not unheard of for platforms which started out no-code later REGRESS and introduce coding features such as APIs because as it turns out, no-code is intrinsically limited in a lot of very significant ways. When I use a "no-code" product it's usually not more than a few months before I start using it's API and adding small bits of code here and there to do things not natively supported by the product. You would have to have a puritanical fervor and a lack of sense to want to eliminate all semblance of code from a product made out of code. It's almost as if after seeing you could add images to Microsoft word documents you saw an article coming out about how Written English was going to be replaced by Hieroglyphics and soon we could communicate with nothing but Emoji and talking about how the next generation won't be literate. The sentiment in this thread is mostly a reaction to irritating and implausible clickbait.
  - michaelmrose 6y ago
    Well put especially the last bit.

lordnacho 6y ago

I get this hunch that no-code is attractive because it hides the true costs. You can apparently hire cheaper labor, but you don't see the maintenance costs. You can also apparently delegate coding tasks to non-coders, which might help you squeeze the budget bubble around the business. But there's costs to that as well in terms of making people less effective at their normal work.

TheOperator 6y ago

A third of the websites in the world use wordpress which can certainly be configured using "no-code" and yet it's being sold as something brand new. Excel is everywhere and allows for "no-code" automation. No-code has been around forever and for some reason incremental improvements to something utterly pervasive is a revolution that will be embraced by the next generation. All I can think of is how Windows used to be administered almost entirely through the GUI but eventually PowerShell was invented and its popularity grows year over year. How is that even possible when the "no-code" way to administer Windows must clearly be better and more accessible and user friendly and coding is old fashioned and borderline obsolete? Every company with their heads on straight would fire anybody who uses PowerShell and replace all their admins with unskilled high school graduates. There is not enough room in town for both no-code and code solutions, so I expect Microsoft to remove PowerShell in it's next update.

msla 6y ago

"No code" as a term sounds like "serverless": There's a blatant contradiction in the terminology, but if you point it out, people begin to snicker up their sleeves at the person who reads the words as if they were English. There's definitely a place for a la carte pricing for server-based software ("serverless" which of course includes servers, you silly person) and there's a place for very high-level code in domain-specific languages to solve immediate business problems ("no code" which of course includes writing code, you silly person) so just learn the shibboleth and try to avoid sounding silly. /s

vram22 6y ago

> and many other forms of no-code solutions Yes. Also CASE tools, those with a code generation feature. https://en.m.wikipedia.org/wiki/Computer-aided_software_engineering https://en.m.wikipedia.org/wiki/Computer-aided_software_engi...

vram22 6y ago
> with a code generation feature Pun unintended :)

skohan 6y ago

I think the core of the issue is that real problems contain a lot of complexity, and code is still by far the most efficient way to encode complex logic. For instance, I've done some work with node-based editors like Node Red and Max MXP, and while they are nice for simple cases, invariably they reach a tipping point where you end up with a giant graph which is far less navigable and comprehensible than a set of source files. There's no escaping complexity.

fastball 6y ago

Agreed. No-code is only long-term viable once no-code tooling is self-hosted.

sidpatil 6y ago

" When someone says 'I want a programming language in which I need only say what I wish done,' give him a lollipop." Epigram 93, Alan Perlis http://www.cs.yale.edu/homes/perlis-alan/quotes.html http://www.cs.yale.edu/homes/perlis-alan/quotes.html

paulmendoza 6y ago

It is different this time. I am a really good coder but I am using no code tools as much as I can. I only use code for new projects if I absolutely must.

divbzero 6y ago

I share your view that the limits of no-code have been proven time and time again. Just ask the countless devs who have added custom code to WordPress or Squarespace sites. That said, maybe this time is (a bit) different. Machine learning is markedly more mature today and could take no-code farther than it has in the past.

Ma8ee 6y ago
How would machine learning help?