6 ms·

This idea gets recycled every generation. I can’t count how many “low code” no-programming-skills-required tools I’ve seen come and go in the last four decades.

This idea gets recycled every generation. I can’t count how many “low code” no-programming-skills-required tools I’ve seen come and go in the last four decades. Both COBOL and SQL got presented in these terms. I’ve yet to see a “non-technical manager” write a non-trivial SQL query, much less know how to confirm they got the correct results. The various 4GL tools that proliferated in the 90s led to complex amateur spaghetti code apps in Access and FileMaker and 4th Dimension that didn’t scale, with no way to break through the inevitable limitations of the tools. And few people wanted to learn to use those. As other people commented the hard part of programming is not the language or tools, though those can be damned hard to master. Translating requirements into code is the hard part. If that was easy to automate we could have built code from UML diagrams drawn by non-programmers decades ago. The most widely-used low-code tool is Excel, for some time now. Easy to use, sure. Not so easy to use correctly and accurately. https://www.forbes.com/sites/salesforce/2014/09/13/sorry-spreadsheet-errors/ https://www.forbes.com/sites/salesforce/2014/09/13/sorry-spr...

rsj_hn 5y ago
I agree, but there is a kernel of truth here, which is making programming more accessible by means of higher level constructs that are easy to use while also being less general. Excel is a great example, in that it opened up the world of macros and programming to a huge population. Yes, you still need technical skills and programming skills, but the entry bar is lowered in exchange for playing in a tighter sandbox. In many cases, this is a good tradeoff. All the no-code/low-code stuff is just marketing trying to promote this.
- gregjor 5y ago
  The entry bar got lowered back in the 80s with cheap home computers running BASIC. Lots of us learned on low-end low barrier to entry systems like that. There’s no gate keeping. Anyone who wants to learn programming has a wealth of tools and languages and resources to choose from, for free. This is a replay of previous attempts to pretend to democratize programming and reduce the dependence on rare and expensive programmers. Those are real problems but I don’t think we get there by pretending that anyone can build a system out of software Lego blocks. The actual market here is VCs and C-suite managers looking at software dev labor costs, and misunderstanding (and getting misled) about the reasons for those costs.
  - rsj_hn 5y ago
    Yeah, those basic computers were fun, but having an entry level computer you could write basic programs on wasn't going to help you automate business processes, whereas writing an office macro would. That's kindof the point - to embed the functionality with the data and existing applications, so you can think of these "low code" interfaces built into online apps as the cloud version of those old MS visual basic macros. Except some of these added various drag and drop functionality to graphically add some logic, lowering the bar a bit further.
    - gregjor 5y ago
      Well anything can happen. Approaching the end of my career after 40 years programming, I’ve heard for decades (no exaggeration) how low code/no code tools would make me obsolete. For the last decade or two I’ve also heard that AI would be taking my job any day now. I don’t hold my breath. I’ll be writing code until I stop, and I predict that in ten years businesses will have more work for skilled programmers, not less. These low code/no code tools aren’t useless, but the people who are most likely to buy them are not likely to put in the 5+ years to learn more about programming. If they do they will want to move beyond the low/no code stuff. If they don’t they will be stuck writing macros to automate their business processes, which eventually means the business is constrained by the low/no code tools.
      - rsj_hn 5y ago
        Extending programmability does not make programmers obsolete, anymore than putting better cameras into iPhones makes photographers obsolete. It's just more tools, and it will even increase the ranks of developers by giving them more onramps. A friend of mine started out writing ActionScript and now he's a full fledged developer. These scripting languages and drag and drop interfaces are useful and so they will be used. No one will be obsoleted by them.
    - hyperman1 5y ago
      I knew a business doing just that with a zx spectrum. Even with the horrors of deafening chain paper printers and software on audio casettes. They had a CRMish application written by a student. They could print their own mailings with individualized coupons. Who cares if it takes a noisy hour in a back room to run. Don't underestimate what people did with those things.
jacquesm 5y ago
I've looked at a whole bunch of low code tools in the last two years and my opinion has shifted from high grade bullshit sold by the clueless to the even more clueless ('Now: coding for managers') to where I believe that the current crop of low code/no code platforms has something real to offer and has staying power for some use cases. Specifically: lots of forms based processing backed by relational DBs with occasional excursions importing/exporting data to and from other systems where the flexibility outweighs any kind of performance and integration issues. Have a look at: Mendix, Betty Blocks, Outsystems. Each of these has something to offer the others do not, and all of them help non programmers or beginner programmers to roll out working applications for themselves and their peers.
- gregjor 5y ago
  Sure. Tools like that have been around since the ‘70s. They have their uses — building forms and reports point-and-click. But the limited scope and inevitable low ceiling of capabilities means they did not spell the end of programmers. Instead they expand the market because the non-programmers will need help when they outgrow their tools, or even sooner when they can’t figure out a JOIN or GROUP BY or how to handle record locks.
  - jacquesm 5y ago
    No, this is a lot better than what was sold during the 70's, 80's and up to the mid 2000's. I'm aware of all of those developments, was regularly pitched about them and have evaluated the bulk of the solutions on offer, from Mimer, Mapper and other mainframe based solutions to the various offerings on PCs and UNIX platforms. Those are not to be compared to the three I mentioned above. Agreed on the fact that these lead to market expansion and that they typically are only good up to a certain point but the examples you give are solved problems for a long time now.
    - garyrob 5y ago
      "Mendix, Betty Blocks, Outsystems" Interesting. I've never even heard of any of those products. They must be in some completely different space than I'm operating in. In 1980 I was a database consultant, with a long-term account at NY Telephone. Their marketing department mainly used a 4GL called NOMAD. I have to say, it was really great for creating hierarchical databases and for formatting complex reports from it. In fact, when I moved on from that world, I've always missed it since then. Nothing I've used since then has actually worked as well as NOMAD for the purpose of generating reports from data. SQL did many of the same things, but not as easily. (And even though it was based on a hierarchical DB, you could do operations that were basically SQL's joins. So it was both relational and hierarchical. Although I'm not sure whether the word "relational" was used in that way at the time.) And at that time there was talk about how in 10 or 20 years even those 4GLs wouldn't be necessary any more because software would generate itself from specifications. I sure haven't seen that happening. In fact, my personal experience has been that, at least for what NOMAD was built to do, nothing since then has even done it as easily. But then again, I haven't even heard of the tools you named!! Are they just not popular yet because they haven't had time to reach their full audiences, or are they only used in very specific niches such that they don't have a lot of presence in places such as Hacker News?
ozim 5y ago
Translating requirements into code - is about language and tools as you have to learn the language, as you noted "few people wanted to learn to use those". Third paragraph is saying about loads of amateur spaghetti code, so turns out it was not that hard. So third paragraph contradicts things written in the second. Low-code tools promise to address "problem of the language" so it is easy to translate business knowledge into the tool. Keep in mind low code tool should ideally be used by domain expert, so another promise is that you don't need business analysts and developers so problems with communication or misunderstanding is removed. Going back to second paragraph: Good part that was noted, there were loads of spaghetti apps in Access and File maker, let alone all those Excel sheets that are still everywhere. There was no one to maintain them and low code tools don't provide enough means for maintaining complex systems. Running and maintaining computer systems is 80% of cost for software, maybe translating it into code is hard, but debugging, fixing, adjusting, keeping operational knowledge is much more expensive. Silly Excel file that architect Jane was using for 5 years and then she quits, you hire John while you can do knowledge transfer - it is still hit or miss just as noted in second paragraph John will be more comfortable doing his own excel from scratch than learning what Jane did. Even with developers it is the way that everyone wants to do "greenfield" and understanding what other people wrote before in some unfamiliar system is hard work. Low code even makes it harder to understand existing stuff with their GUIs. Whole DevOps tooling/movement grew just because of that fact, none of the "low-code" tools is addressing it.
- lwhi 5y ago
  > Translating requirements into code - is about language and tools as you have to learn the language, as you noted "few people wanted to learn to use those". I'd actually argue differently. It's more about a design process that requires domain knowledge, technical knowledge and the ability to assess a problem contextually. Coding is only part of this process.
  - ozim 5y ago
    Keep in mind low code tools should ideally be used by domain expert directly as I wrote in my post.
zozbot234 5y ago
The actual, meaningful goal of some of these tools was to make code (via COBOL, SQL) or at least high-level design (UML) easier to audit and survey for non-technical stakeholders, so that one could check whether requirements had been correctly translated into code. In contrast, many and perhaps most "4GL", "low" or "no" code tools actually make it quite hard or even practically impossible to assess the resulting artifacts. Even MS Excel and other spreadsheets can introduce dangerous pitfalls, including in something as simple as correctly inputing data. In theory it is of course quite possible to introduce special-cased abstractions, conventions or frameworks that really make it easier to both write and survey software for any given problem domain. As a matter of fact though, beyond existing lightweight software modularization efforts (such as reusable software libraries), such frameworks have tended to hurt rather than help.
RickJWagner 5y ago
My thoughts exactly. I remember the hype around 4GLs and CASE. IMHO, it's the test/validation discipline that makes the difference. No matter how easy the tooling, the 'test before production' mentality is the barrier that proves necessary to overcome.
aryehof 5y ago
> Translating requirements into code is the hard part I so agree. However, I don’t think that a majority of the new generation of developers would. Technologies, platforms, frameworks, user and system interfaces, and how to best modify persistent data is what many would say is the hard part. With this viewpoint, the pursuit of automation into no-code tools is much more understandable in my opinion.

rsj_hn 5y ago

I agree, but there is a kernel of truth here, which is making programming more accessible by means of higher level constructs that are easy to use while also being less general. Excel is a great example, in that it opened up the world of macros and programming to a huge population. Yes, you still need technical skills and programming skills, but the entry bar is lowered in exchange for playing in a tighter sandbox. In many cases, this is a good tradeoff. All the no-code/low-code stuff is just marketing trying to promote this.

gregjor 5y ago
The entry bar got lowered back in the 80s with cheap home computers running BASIC. Lots of us learned on low-end low barrier to entry systems like that. There’s no gate keeping. Anyone who wants to learn programming has a wealth of tools and languages and resources to choose from, for free. This is a replay of previous attempts to pretend to democratize programming and reduce the dependence on rare and expensive programmers. Those are real problems but I don’t think we get there by pretending that anyone can build a system out of software Lego blocks. The actual market here is VCs and C-suite managers looking at software dev labor costs, and misunderstanding (and getting misled) about the reasons for those costs.
- rsj_hn 5y ago
  Yeah, those basic computers were fun, but having an entry level computer you could write basic programs on wasn't going to help you automate business processes, whereas writing an office macro would. That's kindof the point - to embed the functionality with the data and existing applications, so you can think of these "low code" interfaces built into online apps as the cloud version of those old MS visual basic macros. Except some of these added various drag and drop functionality to graphically add some logic, lowering the bar a bit further.
  - gregjor 5y ago
    Well anything can happen. Approaching the end of my career after 40 years programming, I’ve heard for decades (no exaggeration) how low code/no code tools would make me obsolete. For the last decade or two I’ve also heard that AI would be taking my job any day now. I don’t hold my breath. I’ll be writing code until I stop, and I predict that in ten years businesses will have more work for skilled programmers, not less. These low code/no code tools aren’t useless, but the people who are most likely to buy them are not likely to put in the 5+ years to learn more about programming. If they do they will want to move beyond the low/no code stuff. If they don’t they will be stuck writing macros to automate their business processes, which eventually means the business is constrained by the low/no code tools.
    - rsj_hn 5y ago
      Extending programmability does not make programmers obsolete, anymore than putting better cameras into iPhones makes photographers obsolete. It's just more tools, and it will even increase the ranks of developers by giving them more onramps. A friend of mine started out writing ActionScript and now he's a full fledged developer. These scripting languages and drag and drop interfaces are useful and so they will be used. No one will be obsoleted by them.
  - hyperman1 5y ago
    I knew a business doing just that with a zx spectrum. Even with the horrors of deafening chain paper printers and software on audio casettes. They had a CRMish application written by a student. They could print their own mailings with individualized coupons. Who cares if it takes a noisy hour in a back room to run. Don't underestimate what people did with those things.

jacquesm 5y ago

I've looked at a whole bunch of low code tools in the last two years and my opinion has shifted from high grade bullshit sold by the clueless to the even more clueless ('Now: coding for managers') to where I believe that the current crop of low code/no code platforms has something real to offer and has staying power for some use cases. Specifically: lots of forms based processing backed by relational DBs with occasional excursions importing/exporting data to and from other systems where the flexibility outweighs any kind of performance and integration issues. Have a look at: Mendix, Betty Blocks, Outsystems. Each of these has something to offer the others do not, and all of them help non programmers or beginner programmers to roll out working applications for themselves and their peers.

gregjor 5y ago
Sure. Tools like that have been around since the ‘70s. They have their uses — building forms and reports point-and-click. But the limited scope and inevitable low ceiling of capabilities means they did not spell the end of programmers. Instead they expand the market because the non-programmers will need help when they outgrow their tools, or even sooner when they can’t figure out a JOIN or GROUP BY or how to handle record locks.
- jacquesm 5y ago
  No, this is a lot better than what was sold during the 70's, 80's and up to the mid 2000's. I'm aware of all of those developments, was regularly pitched about them and have evaluated the bulk of the solutions on offer, from Mimer, Mapper and other mainframe based solutions to the various offerings on PCs and UNIX platforms. Those are not to be compared to the three I mentioned above. Agreed on the fact that these lead to market expansion and that they typically are only good up to a certain point but the examples you give are solved problems for a long time now.
  - garyrob 5y ago
    "Mendix, Betty Blocks, Outsystems" Interesting. I've never even heard of any of those products. They must be in some completely different space than I'm operating in. In 1980 I was a database consultant, with a long-term account at NY Telephone. Their marketing department mainly used a 4GL called NOMAD. I have to say, it was really great for creating hierarchical databases and for formatting complex reports from it. In fact, when I moved on from that world, I've always missed it since then. Nothing I've used since then has actually worked as well as NOMAD for the purpose of generating reports from data. SQL did many of the same things, but not as easily. (And even though it was based on a hierarchical DB, you could do operations that were basically SQL's joins. So it was both relational and hierarchical. Although I'm not sure whether the word "relational" was used in that way at the time.) And at that time there was talk about how in 10 or 20 years even those 4GLs wouldn't be necessary any more because software would generate itself from specifications. I sure haven't seen that happening. In fact, my personal experience has been that, at least for what NOMAD was built to do, nothing since then has even done it as easily. But then again, I haven't even heard of the tools you named!! Are they just not popular yet because they haven't had time to reach their full audiences, or are they only used in very specific niches such that they don't have a lot of presence in places such as Hacker News?

ozim 5y ago

Translating requirements into code - is about language and tools as you have to learn the language, as you noted "few people wanted to learn to use those". Third paragraph is saying about loads of amateur spaghetti code, so turns out it was not that hard. So third paragraph contradicts things written in the second. Low-code tools promise to address "problem of the language" so it is easy to translate business knowledge into the tool. Keep in mind low code tool should ideally be used by domain expert, so another promise is that you don't need business analysts and developers so problems with communication or misunderstanding is removed. Going back to second paragraph: Good part that was noted, there were loads of spaghetti apps in Access and File maker, let alone all those Excel sheets that are still everywhere. There was no one to maintain them and low code tools don't provide enough means for maintaining complex systems. Running and maintaining computer systems is 80% of cost for software, maybe translating it into code is hard, but debugging, fixing, adjusting, keeping operational knowledge is much more expensive. Silly Excel file that architect Jane was using for 5 years and then she quits, you hire John while you can do knowledge transfer - it is still hit or miss just as noted in second paragraph John will be more comfortable doing his own excel from scratch than learning what Jane did. Even with developers it is the way that everyone wants to do "greenfield" and understanding what other people wrote before in some unfamiliar system is hard work. Low code even makes it harder to understand existing stuff with their GUIs. Whole DevOps tooling/movement grew just because of that fact, none of the "low-code" tools is addressing it.

lwhi 5y ago
> Translating requirements into code - is about language and tools as you have to learn the language, as you noted "few people wanted to learn to use those". I'd actually argue differently. It's more about a design process that requires domain knowledge, technical knowledge and the ability to assess a problem contextually. Coding is only part of this process.
- ozim 5y ago
  Keep in mind low code tools should ideally be used by domain expert directly as I wrote in my post.

zozbot234 5y ago

The actual, meaningful goal of some of these tools was to make code (via COBOL, SQL) or at least high-level design (UML) easier to audit and survey for non-technical stakeholders, so that one could check whether requirements had been correctly translated into code. In contrast, many and perhaps most "4GL", "low" or "no" code tools actually make it quite hard or even practically impossible to assess the resulting artifacts. Even MS Excel and other spreadsheets can introduce dangerous pitfalls, including in something as simple as correctly inputing data. In theory it is of course quite possible to introduce special-cased abstractions, conventions or frameworks that really make it easier to both write and survey software for any given problem domain. As a matter of fact though, beyond existing lightweight software modularization efforts (such as reusable software libraries), such frameworks have tended to hurt rather than help.

RickJWagner 5y ago

My thoughts exactly. I remember the hype around 4GLs and CASE. IMHO, it's the test/validation discipline that makes the difference. No matter how easy the tooling, the 'test before production' mentality is the barrier that proves necessary to overcome.

aryehof 5y ago

> Translating requirements into code is the hard part I so agree. However, I don’t think that a majority of the new generation of developers would. Technologies, platforms, frameworks, user and system interfaces, and how to best modify persistent data is what many would say is the hard part. With this viewpoint, the pursuit of automation into no-code tools is much more understandable in my opinion.