80% of tech could be built outside IT by 2024, thanks to low-code tools | Hacker News Reader

80% of tech could be built outside IT by 2024, thanks to low-code tools

venturebeat.com

74 pointsthrowaway2016a223 comments

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

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.

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.

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.

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.

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.

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.

> 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

Yes, it was, and lots of people with those computers and small businesses used them to do exactly that. (And others used them to do the same thing with household “business processes”.)

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.

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.

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.

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

I'm aware of NOMAD, fond memories in fact :)

Yes, they are somewhat niche. Mendix got bought out by Siemens, Betty Blocks is an interesting dutch start-up. I came across all three of them in the last year and they've made me re-consider my point of view towards no-code/low code environments, which I used to believe are niche and/or toys. I think they are entering the mainstream and will find a spot somewhere between 'excel' and proper programming (in so far as stringing together API calls is still proper programming ;) ).

We’re not disagreeing. The new batch of no-code/low-code tools may find a niche and help some non-programmers solve real problems. I see that with Excel, WordPress, Shopify, even SalesForce and Hubspot all the time.

I don’t agree that “80% of tech” (whatever that means) will be built by non-programmers in two years. The hype about new tools (or AI) replacing skilled programmers comes around like clockwork because lots of managers and executives would love to see that happen. Programmers are expensive, in-demand (so hard to find and keep) and often temperamental and hard to manage. That part of the dream is bullshit. If these tools do find a niche they can only expand the amount of software out there, creating a larger pool of work for programmers.

Microwave ovens didn’t replace regular ovens and stoves, nor did they democratize cooking for the masses. No chefs hung up their hats and said “game over.” They are a convenience, a shortcut. If you want a real meal you cook or have someone who knows how cook for you.

Mapper - I've still got the t-shirt somewhere :-)

I have seen SaaS application owner who was thinking he could do SaaS with low code and cut the costs.

On his place I would be selling "low code" but that guy was severely shortsighted.

I'm sure there are countless examples of this. But even so: there is a vast number of applications out there that are more complex than 'excel' and much simpler than 'bespoke software', and that niche is widening as these platforms become more capable.

I don't see it that way.

In the moment that you want to have multiple users working on the same Excel/Dataset and changing formulas/calculations/rules it is basically bespoke software. Well good luck changing stuff by each employee on their own.

Because there will be appointed one employee who will be making changes for that and as such "Excel" grows he will end up not working on whatever he was expert for but on maintaining that bespoke software.

I don't see low code platforms solving maintenance issue, they promise that you will be able to write code quicker and without developers.

When you get one of the employees working full time on updating and maintaining some low code, he becomes developer. Well you pay him the same salary and you don't have to shell out money for Java/.NET guy but you will pay for license on that platform. While you will be able to hire next Java/.NET dev, good luck finding that specific platform developers. Salesforce if probably going into good direction building their "consultants" base, where I don't see fundamental difference between "consultant" and "developer". Maybe you don't need consultant day in/ day out but they still charge like you would have them hired full time.

In the end I am biased because I am a dev and businnes risks I see are from different side than business people.

But as with Salesforce or any other CRM I see it as a huge lie as the system gets bigger and complex there is no running away from dedicated people doing maintanence. You just tie yourself to a proprietary tool where with Java/.NET you still tie yourself to an ecosystem but it is basically for free and you keep unbounded flexibility.

> I don't see it that way

> In the end I am biased because I am a dev

I agree :)

Unbounded flexibility for one party spells 'nightmare' for another... as with every other tool: use where applicable and don't try to stretch it too much to solve something it wasn't intended for and you'll be fine. Your job is not at risk from low/no code tools. It will simply open up a different class of problems to an intermediate level of automation.

Thanks for agreeing :)

Unbounded flexibility is what most of business people expect. I am always a bit sad when I see the look on their faces when I have to tell them that their great idea is going to cost 5x more because they wanted their previous great idea ASAP/cheap/#timeToMarket and we have to build on top of that.

I just imagine how it must look when someone tells "sorry, it is not possible, because our low code platform does not support something like that".

As someone still in the skeptic camp: what's a good example of a small, effective application that one of those products could help someone to build?

One example I've seen up close that was quite impressive was workflow automation in an insurance company. Frequent changes to business models, legislation and customer requirements made flexibility the main driver of their development and the people with the most knowledge were able to directly modify the application.

It wasn't even small, it was quite complex, replaced a very large number of spreadsheets and worked - and works - to satisfaction of all participants. Getting that same system built using regular tooling and processes would have cost that company a large multiple and would not have been nearly as flexible.

Do ETL[1] and data analysis applications count? There are several pretty good visual ETL and data analysis tools around that let non-coders write pretty advanced and useful processes. Personally, I consider FME (www.safe.com) one of the greatest pieces of productivity enhancing software I've ever used.

That being said, as someone who works with those sorts tools, the quality of the solutions programmers can come up with using those tools tend to far outshines the quality of the solution non-programmers make. There is something about the computational and algorithmic way of thinking that programming teaches that most people who haven't learned how to program have a hard time wrapping their heads around.

[1]https://en.wikipedia.org/wiki/Extract,_transform,_load

>visual ETL

The one I've seen, Apache NiFi, is essentially a giant footgun. Giant, cumbersome, and does not deliver on it's promises - requires teams of engineers to make sure anyone won't fuck up the system for everyone else. And of course, possibilities for data loss and duplication are endless.

In a lot of cases, end users are just providing a replacement for things they did manually, and badly, with emails, spreadsheets, and attachments.

The most common pattern I see implemented is a request, tracking, and approval flow. For things like time off, or borrowing equipment, or volunteering for some duty, etc.

There is an assumption that code syntax is the difficult part about building applications.

For many people this is true.

It may be true that syntax is difficult for some to master, but in that case it's still not "the" difficult part; actually understanding requirements, use cases and implementing logic will always be more challenging.

Perhaps this is a cultural thing, but I'm comfortable saying I've taught at least 250 people to code and absolutely 0 of them were capable of programming right when they had learned just the syntax. For most of those students the difficult part was structured thinking without deviation and carefully stepping through their own code mentally to figure out if they were going to write something that made semantic sense.

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.

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

Keep in mind low code tools should ideally be used by domain expert directly as I wrote in my post.

Designing a software product also requires (software design) domain expertise.

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.

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.

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

2016:

- Some day, we won't even need coders any more. We'll be able to just write the specification and the program will write itself.

- Oh wow, you're right! We'll be able to write a comprehensive and precise spec and bam, we won't need programmers any more.

- Exactly

- And do you know the industry term for a project specification that is comprehensive and precise enough to generate a program?

- Uh... no...

- Code, it's called code.

https://www.commitstrip.com/en/2016/08/25/a-very-comprehensi...?

I lol'd in real life at that one. Nice.

I feel like we will have successful no-code tools at the same time as we stop having lawsuits, when we have laws that have zero loop holes and correctly specifies how to handle 100% of edge cases. In other words, probably never.

This may not be a popular opinion, but I can't help but think that though the claims are a bit grandiose the fundamental thesis statement is true?

IE: Each generation sees a "simpler" toolset being made available which opens up programming to a wider audience.

If assembly was still the only way to program we would have fewer programmers, same with C, or dynamic languages. Javascript and the web opened up programming to a whole host of new people.

They're all code, but you can't tell me that an assembly program is the same as a python program for example.

I'm not trying to say that these newer ecosystems are better or worse exactly. Just that each new generation opens up this field to people who would have never picked it up beforehand and we as a society are richer for it.

We see more apps/tools developed to serve a wider array of people's preferences and use-cases. Sure there are new problems, but I like the direction we're going.

I agree, the more code spreads and becomes accessible the more programmers are needed. I believe no-code/low-code will grow but it won’t eliminate programmers, it will just create a new strata. I think the new challenge will be to distinguish between all the different types of programmers in a meaningful way. How do you classify the business analyst who codes using visual languages vs. the data scientist scripting python vs. the javascript web developer vs. c++ systems developer vs. embedded developer, etc.”Programmer” - “software engineer” are starting to become too non-specific.

Compilers may get better but business logic rarely gets simpler and specs rarely more refined

Sure, but if you dont have to translate requirements and a end user can build their own solution, you save alot of overhead.

So by writing code? ;)

Many end users don't have the vocabulary in their own business language to formulate their requirements. How will a solution magically appear?

> IE: Each generation sees a "simpler" toolset being made available which opens up programming to a wider audience.

Nope.

---

A frontend developer.

This is a song we've heard before: the 4th generation programming languages [1]. They failed completely.

Programming is no more about "the codes" than writing novels is about spelling.

The difficulty in writing novels is being able to tell a story well (just like some people a good at telling jokes, others not). It is not about how good you are at spelling words. Most winners of spelling bee competitions never become good authors.

You can't make most people into being good authors by handing them a tape recorder.

1: https://en.wikipedia.org/wiki/Fourth-generation_programming_...

I feel like it didn't really fail because of the technical aspect, but rather a business one.

Once such a tool is successful, there will be lock-in and/or slightly incompatible competitors. You, as a user, become dependent on single company, which is almost always abused in the end. Both factors are driven by the complexity of the systems that were built with the tool (the complexity hides in the tool, which made these systems easy to write in the first place).

A similar thing IMHO happened to Unix, Common Lisp.. the only way to avoid the fate is to establish and maintain a common standard, but that means yielding the power (it's not particularly appealing business model) and is a subject to the tragedy of the commons, and embrace/extend/extinguish.

this!

exactly- even though I have read many interesting other reasons why this will not work out.

programming is about modeling and formulating a problem so that a machine "understands" it and can execute it.

Not so many people can and want to do it well...

It's been around 8 years since this happened: I started learning R and a Gartner consultant told me I was wasting my time because, "as Gartner puts it", the future of data science is citizen data scientists with very little coding skills because the tools and frameworks will do all the heavy lifting. I ignored him because I liked the language anyway.

I guess every now and then someone will try to sell a tool to "build nerd things without the nerds!" be it web dev, data science/engineering, ux, devops, whatever.

I will believe in it only when I see it: everyday fellas building sustainable saas businesses on their own, without coding.

I'm less skeptical towards little internal applications though. Those don't need to be good as standalone products, they just have to be better than shitty forms/sheets and cruds companies use internally. In that space I think Retool is doing something cool and interesting.

This. I've just built out an internal CRM for my travel company using Airtable+StackerHQ.com and for my business, it's hands down better than anything commercially available... because it covers all the nuance of our individual situation.

2 months ago, I was a bit down on no-code, but the experience on building on Stacker was good enough to change my mind. Softr.io is also getting there, too.

> because it covers all the nuance of our individual situation.

Without wanting to downplay your achievement, I've worked for organisations that did the same thing with MS Access back in the early oughts.

The 'custom' application grew with the organisation. Features were bolted on over the years inelegantly. It was impossible to integrate easily with other systems.

The quirks of the system were known by long time employees who developed work arounds that were convoluted and took time.

UX wasn't a thing back then; but if it had been people would have definitely said it had terrible UX.

We've been promised these solutions for a long time. In my experience, they overpromise and underdeliver.

overpromise and underdeliver.

Something that under-delivers is much more useful that something that doesn't exist. In most situations and most companies the the choice is never between the ugly Access thing and top quality software written by team of highly educated professional programmers. It's a choice the between the ugly Access thing and an ad-hoc collection of text files and post it notes.

> Something that under-delivers is much more useful that something that doesn't exist.

No. I disagree.

Sometime a badly constructed solution is worse than no solution.

> It's a choice the between the ugly Access thing and an ad-hoc collection of text files and post it notes.

I think this was definitely true before the advent of SaaS products.

I understand your point. The reality is that no solution will ever be perfect, be it an off the shelf SaaS or my homebrew no-code build.

There are a few things here which help us;

- Airtable has all the integrations a human being could ever need. Our stack is Airtable + Stripe + Zapier + Wordpress + ActiveCampaign.

- General awareness of the concept of UX. You need a product owner who fiercely defends the product. And .. you need a company culture which treats employee satisfaction as something that actually matters. I know that these things not common.

- I have no viable alternative. SaaS companies in the tour & activity space struggle to make money and struggle to invest in their product.

- A community of contractors. Airtable has a large community of able freelancers and contractors who can come help us out, if needed.

Thanks for your comment, I just looked at AirTable and StackerHQ. A quick question: is there a way to export your data to standard file formats, just in case you wanted to move off the platform to other vendors or write everything yourself?

I think that getting started quickly on a system that you will likely never have to leave makes a lot of sense, but it is good to have an exit strategy. Like with Heroku: keep running small projects there, but being able to move to alternatives.

Yes, Airtable is exportable. That's part of the reason I chose this solution. I'm big on redundancy.

I think low code tools have come a long way. I also think the problem with low code tools is the specific problematic edge cases or implementation cases that make it hard to do without the more robust capabilities of actual code. That, and the baseline that if you can produce a low code program, you can code, for which the barrier of difficulty is constantly lowering anyway with more and more robust libraries and tools.

Generally I share your skepticism, but a lot of BI tools are low-/no-code. Generally you can't build a SaaS platform on them any more than you can build it on Excel.

That's a great point, thanks.

I deal with Microsoft’s PowerBI and it is true that somewhat normal people can do a lot but the generated result ends up extremely inefficient and we usually end up getting sql experts in to manually write the queries anyway because it costs an obscene amount for the resources to run these auto generated reports.

Looker is the best example IMO.

Don't bother with "no code" but make it a lot easier for people to write the code/markup and also much easier to edit en masse (one sed command in a Github repo, rather than editing every single dashboard separately in Tableau/PowerBI).

If someone can build a low/no-code product, then the barrier to entry is so astonishingly low and there will be a ton of competition for that product. Another consideration is that these low/no-code products almost always cost money.

So not only will the market be flooded with clones, rent-seeking from the provider will eat into margins.

Much like the cloud is someone else's computer; SaaS is someone else's programmer.

It's not like the barrier to learning basic Python is that high. Or Excel macros.

The “someone else’s programmer” metaphor isn’t totally accurate, because of a key difference between cloud vendors and no/low-code vendors.

To support more customers, a cloud vendor needs to have linearly more computers. A no/low-code vendor, on the other hand, does not need to have linearly more programmers.

I see Excel and PowerApps everywhere across our customers.

I didn’t catch anything in the piece about development that could be a revenue-producing product. Rather, sounded like internal apps that might have been done in Excel or Access plus some VBA goodness back in the day.

As a wise investor once told me, “once it shows up in Gartner, it’s done innovating.”

Ever tried Azure Customvision? Building image classification / object detection models is trivial using this platform. I was highly surprised by the accuracy and low cost... I mean anyone who can upload and tag images can make a production ready image classification model at pretty low cost...

There was a bubble.io app (I tried bubble, didn’t enjoy it) built by a non techie, that is making 30k per month in revenue (I am trying to remember the name). Some of these no code / low code tools are really getting powerful and easier to use, at least for CRUD apps that aren’t complex.

I am guessing there are needs for tons of simple tools and businesses that programmers aren’t aware of, or not interested in working on. These would be met by savvy subject matter experts whose tech skills are good enough to build something with these tools.

Having worked with Mendix and Apex (both low-code tools) for over a year: I wasn't convinced.

Anytime you're trying to color outside the tool's predefined lines you'll be hurting and spending ridiculous amounts of time.

But stay within their lines and you'll be fine.

Because of this I don't see any real use-case for it in the B2C market. That in itself makes the 80% mentioned in the article hard to achieve.

In B2B there are more opportunities for low-code tools, but there too I don't see it working everywhere. Simply put; if you build something from scratch it's going to be a lot better than anything built with a low-code tool and you can easily grab market share by providing a better offering than your competitors. Low-code tools are not the means to out-compete the market.

If you do succeed in the B2B market with a low-code tool offering; likely you'll be building some very customized setup that required a huge investment to get to that point. I'd not be surprised it'll be just as unwieldy and difficult to change as most other software is. And for fixing big issues with your app (performance, complex bugs) you'll be requiring devs who worked and understand all those abstraction layers. Those devs will be extremely rare and hard to come by. I was one; but I am not anymore. It's just not fun to develop in them compared to normal coding; you feel constrained and fixing issues all the time that shouldn't exist in the first place.

However if you consider the huge set of internal tools lots of companies develop and use; yes there indeed is a big market for low-code. Basically use cases that were run in excel are generally great candidates for these tools. And that's a lot of use cases. Not the big money-makers though.

There's a reason Frontpage and Dreamweaver never made it; this won't happen to low-code tools. They have their place, but know their limitations.

> Anytime you're trying to color outside the tool's predefined lines you'll be hurting and spending ridiculous amounts of time.

This is exactly my experience. This comes up a lot when someone tries to take a 'DSL' approach to solve a general problem. "Look what you can do in just one simple line!", and it's true, one line and you've got something working.

Then you ask questions that weren't anticipated. How do I reuse the 5 lines I wrote here in another place? How do I write a test for those 5 lines? Can I log outputs in-between lines?

Those aren't exactly scary questions for any programming language - the answer is trivial, and what those languages solve for. But in these fancy no-code systems the answer is "you can't", more often than not. I care way more about how a system is going to evolve and how it will be maintained than solving trivial problems in one line.

They end up being completely unmaintainable and you lose more time than you save.

Frankly, coding isn't that hard. You don't need to be an expert to be effective, and there's a massive amount of tooling, knowledge-sharing, and investment already there.

All of this no-code shit is such a waste of time.

Predictions like these always overlook where 90% of the software lifecycle really takes place: legacy code.

Code-generators-for-the-masses my be able to create new code but it can't modify, extend, repair, or maintain old code. To change an app, all code generators require that you modify the app's configuration and then generate all new code. That works fine if you know what part of the configuration caused the failure. Otherwise the generator will continue to generate bad code and you're forever screwed. Anyone who generates code from high level specs but doesn't know how the code executes on the computer will be mystified by a misbehaving app or by error messages, and unable to diagnose, must less fix, problems that arise.

Think of a car that's designed and built by automation. If the automaton has no idea how to fix the car when a part fails during its lifetime, the only way it can repair the car is throw the whole car away and generate a new one. But with the problem undiagnosed, the same bad part will cause the second car to fail in the same way the first one did.

The software life cycle is about much more than writing new code.

Excellent point. The only thing worse, in my experience, than legacy code is legacy code that came from a code generator, or an amateur with MS Access or something like that.

The underlying press release [1] uses - as suspected - Gartner's beloved phrasing like "Citizen Developers" aimed at gullible managers who they sell this nonsense to with the wording's warm, fuzzy, implications of saving cash spent on those pesky overpaid techies.

Note that there are no "Citizen Consultants", "Citizen Managers", or "Citizen Snake-oil Salesmen" (where surely far more money could be saved at far less loss to business functionality) mentioned in their ridiculous marketing blogs.

[1] https://www.gartner.com/en/newsroom/press-releases/2021-06-1...

No-code tooling or not someone still has to design the workflow. Designing a workflow requires asking good questions, which requires putting in the time with domain experts who aren't necessarily an expert in implementing a workflow with software.

You'll just get different flavors of specialists this time with newer no-code tools. IT will still probably be doing this work. Writing custom code / using generators might still be more optimal to avoid vendor lock-in that is often the revenue strategy of low-code SaaS.

I don’t even know of good standards-compliant WYSIWYGs for HTML besides maybe(?) Webflow these days, and that's proprietary. I don’t know how you’d do low-code anything today in any meaningful sense.

Of all the people who care about automation, if there were good, viable low-code options, developers themselves would want to use them!

I've used a couple of those website builders you see advertised on YouTube occasionally, and they are pretty good. You can't do complicated custom web applications with them, but that's not what they are designed for. They are designed for building nice, if generic, websites quickly.

Those tools are probably what killed the market for professional WYSIWYG editors.

I happen to build one of them. Have a look at https://pinkpigeon.co.uk and I'll check back in here to answer any questions.

It's worth noting that your point is correct: a no code solution for building websites is inevitably going to be limited in terms of how much customisation someone can do, but one gains speed and ease of use on the flipside.

For sure, square space and Wordpress themes cover almost every case things like dream weaver cover. And then you get mobile support for free which I can’t even imagine how the wysiwyg editors handle.

And even Webflow the value for users is mainly unified platform that includes hosting/dev environment and integrated marketplace of themes and webflow developers. It's really handy to be able to just contract anyone you just share access to.

The editor itself is ok but they've solved html/css by making gui for everything. You are writing html/css and you have to learn it. You just don't realize that. Apart from some animation/interaction there is not that much magic. Give it to someone with no html/css knowledge and you get "brute force" style of writing css where everything is inlined, absolutely positioned and has all possible breakpoints for everything. But i guess thats fine for the marketing pages.

Good low-code tools would be great. But you are still going to need software developers to operate them.

The biggest job of software development is not just coding stuff, it is identifying the problem to solve and engineering a solution. Define a data model, think about which data is needed where, what can be done and so on. And then: properly test it! Develop tests, that confirm your stuff is actually working and safe.

Non-technical people most of the time are not able to come up with working solutions. And they never manage to properly test their software. As a reference check all those horrible Excel/VBA sheets. They are useful, but also a source of a lot of problems.

I didn't read the article as saying low code was going to replace programmers. Or maybe I just assumed it, because there is going to be an ever increasing need for programmers. Low code is a good way to off-load some of the tasks and spread the work out.

I understood it in the way, that in the future non technical end users will create their own software. And I doubt that.

>Non-technical people most of the time are not able to come up with working solutions.

And this is where you are terribly wrong, i have seen excel-sheets with the complexity of an operating-system and they are in use for 10+ years, and yes they have well-known bug but you can work around that...really like a real OS, made by accountants etc.

Well one could argue that accountants are technical (number-wise)

When I first started building applications back in the 90’s, I did it using the only thing I could get my hands on at the time, Access 95. Many of these low-code tools just feel like a web version of that. Form builders, drag and drop, define data types, hook up queries to forms and fields to text boxes and grids. I guess I just got old enough to see the approach come full circle.

That was an explicit design goal of one I worked on a number of years ago.

These tools have their place: they allow smart technical people to be highly productive whilst abstracting a lot of the complexity away.

Low-code tools fill a gap, they're the PHP / Rails / Python for Line-Of-Business / data-driven apps. They allow you to achieve in days what would take weeks in those languages and months in C++.

Agree. And we’ve had those tools available for decades. These new low-code/no-code tools have exactly the same potential user base and exactly the same limitations. No new or even interesting problem is getting solved, just a fresh coat of paint. Or reinventing the flat tire, as Alan Kay put it.

How often do you see commercial or enterprise software written in Access or VBA? What happened to all of those? They either couldn’t grow with the business requirements, or they were so specific and idiosyncratic they couldn’t adapt and constrained the business with their limitations for years.

I've seen a fair number of Access applications that were rewritten simply because they need to work in a web browser. They were otherwise fine.

The system I worked on was specialised but highly capable - it could build applications that are very very hard to get right in PHP (but easy to get kind-of-right-if-you-squint).

What I would really love to see is a top class open source Low Code platform; I believe that it could provide a very nice tool of entry to software development, especially for adults.

In my experience with no-code tooling in the past, it works great as long as you stick to the narrow use cases it was designed for and are satisfied with that.

As soon as you want to do anything advanced that the no code tooling doesn't already handle, it gets ugly and complex, and you have to bring in specialists who know how to modify the system or work around it, and that requires coding and IT specialists.

It always happens that people want the application go beyond what the no-code tooling was designed to handle and behave in some particular way that requires advanced functionality and coding. Not once have I ever seen it go any other way. Organizations are attracted by the simplicity and speed of no-code development, but they always want it to something that goes beyond that tooling.

Does that mean that no-code tooling is useless? No. Just expect that it is limiting and you will likely require coding specialists to supplement the things that can be done without code.

If this looks preposterous, one way to see that it could be true is to look at which 80%.

80% of all types of software? No. 80% of the type of software you are building? No.

Almost all of a new category of software that is only economical to create because such tools exist? Perhaps, yes.

Small simple tools, things only needed for a couple of months, things that used to be spreadsheets or physical whiteboards. Things that are useful, and better digitised, but nowhere near worth the cost of building as custom software.

All kinds of companies of all sizes are full of such things. The domain is massive. Arbitrary dates aside, I think it's clear the trend is correct - we will see a lot of growth in this category of software and the tools used to build them.

I'm working on such a tool at Stacker (YC S20). If you're intrigued by what I've said, we're hiring! email's in my profile :-)

I spent half of last year working on a project built using a low-code tool that will remain nameless. The company that produces it had recently raised money at a valuation in the 9 figures if memory serves me.

The project took something like 5x longer to complete than it should have. We spent almost the entire time working against the tool to try to figure out how to do pretty basic styling and/or logic.

We discussed at some length during the project what use cases the tool actually would require less work to implement. There were a few, but they were essentially just the exact workflows which had been implemented in their examples and/or were obviously easy to do given what tools you got from the toolchain.

Edit: Just checked. The funding was at a 10 figure valuation actually (more than a billion). It's hard to believe.

The problem with programmers' perception of low-code tools is that it's dominated by tools and promises that didn't deliver. But low code is here, and it's here right now. Wordpress, Squarespace, and Wix make personal websites and portfolios easy. Google Forms let you intake data and process it easily; it's perfect for (event/organization) registration, surveys, mailing lists, and more. Then there's Doodles to help folks agree on scheduling. Google Forms and Doodles are already used ubiquitously outside of IT. Let's not forget Excel and Google Sheets, the low-code tools that make the world go 'round.

Note that this has nothing to do with the number of programmers. Other industries and regular folks using tech more says nothing about the number of software specialists needed in the future. The demand for software specialists is likely to increase.

Timing is dubious but I can picture a situation in which some version of 80% (by capitalized cost e.g.) of enterprise CRM, ticketing software, ERP, etc. is configured through something you could legitimately call "low code". I think it's already the case in many places.

I also predict that it will become more and more of a bloated mess, because of lower skill people working on it "anyone can set it up easily, no coding required!" and increasing complex reinvention of the wheel that will have to come up in working around whatever limitations make it "low code" in the first place. Again, enterprise software is well down this road.

Eventually, there will be a backlash and disruption of the enterprise market from something we haven't thought of yet that is way better than what we have to put up with today.

Maybe you have used SAP or Salesforce, or any number of customizable enterprise apps like that. If you wonder how companies get hacked and get their databases stolen or ransomed every day, this is how it happens.

As a programmer, I am hoping the low-code future comes true.

Many of the comments here seem critical (and rightly so). It is naturally to be critical as the no-code/low-code approach overpromised before, and its hypothetical success (if ever) will threaten the job security of the many in the HN crowd.

However, the existence of low-code tools means that coders can focus more on the complex problems and/or work with these tools on a higher abstraction plane. This sounds like a win to me, and this is how many technical fields advance -- increasing productivity by automating and abstracting away the lower-level tasks.

There is nothing that prevents a programmer from using a low-code tool. Maybe though a DSL API?

YAML developer? No thanks, take a look at DevOps to get a peak of how it looks like.

The problem with low-code isn't that it's going to take away my job, it's that my job is going to get harder because low-code tools don't make it possible to do every task with code. If you're stuck using a closed-source tool that gates certain functionality behind a UI and doesn't provide an API to automate it, then you've got to either replace the tool entirely, or put a human in the loop doing a repetitive task.

This is exactly how I feel, I just wonder if they can work together? If a company wants some basic CRUD / form / report functionality, please use a tool to build it - it's absolutely mind numbing to develop. But what if it needs to integrate into another system, or needs to be combined with an external source and produce results (trying to name things possibly outside of the tools scope) - how can we as developers hook into it? Are they stuck with the tool unable to fulfill their business needs / weird hybrid things / move away from the tool?

It's gonna be interesting when it happens.

I hope every single low code app either fails or somehow increases the demand for real programmers.

Programming is one of the few jobs that e.g. autistic people can do and still earn a living wage.

It is a tragedy to see it replaced by another opportunity for rent seeking and grift by “low code” app companies.

Something I've realized about programming as a profession is that people hire developers to build even stuff that's mostly cookie-cutter, because nothing is ever totally cookie-cutter. Every CRUD app has a few weird edge-cases that aren't covered by the framework (or low-code tool), and require you to bail out and code around it.

It’s almost like people are paying for an actual human to sit around all day and unscrew things and make sure servers stay up! I wonder if servers will ever just keep themselves up?

Just put it into the cloud. It will stay afloat by magic.

Whelp, time to hang up the ol’ compiler again. Jokes on the author, though. 80% of tech is already built outside of IT, then they find out they need us to clean up their mess.

Like the coding is the hard part

Honestly? I hope so. Problems that can be solved by 'low-code tools' are boring. There will always be more difficult problems to solve that fall outside of the basic use cases (e.g. CRUD / forms) and I'd rather be working on those.

Though I do think there will still be work for programmers, there will always be some point where the business wants something that isn't supported by the tool - just wonder if those low-code tools allow for customization (e.g. plugins).

For crud and form apps there are tools that will generate forms from just a schema. Problem is auto generated forms aren’t the most friendly and they can’t have advanced logic behind them. It’s essentially just more structured spreadsheets.

That title is painful ("could be" = meaningless, and 80%? why not 85?), but the thread is surprisingly good, and who doesn't love an old "this comes up every decade" smackdown. Visual programming anyone?

It really does come up every decade:

https://modeling-languages.com/last-one-code-generator-basic...

There is a progress in computers doing more of the stuff that programmers used to do:

* first we had assemblers and programmers did not need to remember all those binary codes

* then we had compilers and programmers could use the multitude of programming abstractions

* then we had 'scripting languages' that abstracted away even more details

In parallel we also have better libraries that implemented many other abstractions and we also had complete applications that did not need to be written from scratch.

So computers do more and more - and also end users can do more and more by using ready made applications and sometimes linking them together (and maybe becoming programmers in the process little by little). But there is still work for programmers - because the skill of solving problems algorithmically is still special.

My two predictions:

1. A higher level of abstraction will come along that ends up getting used much more than the current most popular level of abstraction.

2. The same people and same type of people that worked in the old lower abstraction layer will work in the new higher one.

This has happened a bunch of times with computers already. I see no reason that this time point 1 will happen but point 2 won't. And, the article really didn't convince me.

They have been saying this for years. I’ll start believing it once I have been replaced by some no-code hack that graduated a 2 week boot camp in <insert some “low code” company here>.

Anybody remember “dream weaver” for front end development? Thus was supposed to change the game, yet all we got was unmaintainable, and bloated code.

When I aged out of the cool jobs I figured out how to make a good living as a freelancer mopping up these messes, or replacing them. Dreamweaver and WordPress were the best things to ever happen to programmers who have the stomach for it — bottomless pit of maintenance work. Because the customer depends on these half-baked solutions they will pay me double or more what they paid their nephew who “is good with the computer” to write them.

I have managed to earn a great living using primarily basic LAMP skills for decades.. but in the next three years it will all come to an end. oh noooooo

This really depends on how you define tech... Is a static website made with SquareSpace tech? Is an excel file tech? I'd argue yes, and if so, then I'd bet that number is much higher than 80%.

So many horse and buggy makers in these comments that can’t see what you see. They think that because some SaaS app they build required so much custom login that low code won’t make a big difference in their world view.

What low code really represents is making automation more accessible for more common tasks without knowing how to develop software. Zapier but for more complex tasks.

20 years ago you had apps like Dreamweaver or Frontpage that enabled this for many people to do static sites like a square space now does dynamic ones.

Sadly though, if history is any teacher, at some point these incremental improvements will create larger low code companies and further consolidate more of the web into a few bigger providers.

Someone who gets it!

Lowcode isn’t designed to replace all code, it’s designed to replace boilerplate CRUD apps with only a thin bit of logic. Often these are the internal apps too that aren’t worth the investment of a “fully coded” solution.

Can't wait to get a few dozen of those boilerplate CRUD apps! Sounds like that's going to take off any time now.

I'm the co-founder of Budibase, an open source low code platform, and 70% of our signups 30,000) are from IT.

Low code abstracts a lot of the coding effort, but it's still inherently complex to build applications. The code is only one part of the puzzle.

For us, it's more about speeding up the dev process for IT profs and removing the repetitive, grunt work.

For ref: https://github.com/Budibase/budibase

I thought that’s what IDEs are for.

IDEs are for speeding up dev too. From our perspective, we were vexed with continually having to repeat ourselves, building the same CRUD tools time and time again. Budibase removes a lot of that repetitive grunt work, and in many cases, you end up with a better, well-designed internal tool.

Cool. I have code libraries and snippets that let me do the same thing. I can put a CRUD app together pretty fast, and the result is customizable, secure, and can scale up for a moderately-sized business.

> I'm the co-founder of Budibase, an open source low code platform, and 70% of our signups 30,000) are from IT.

I'm curious, what makes up the other 30%?

Technical founders, non technical founders, designers, marketers, teachers, students, and lots more

One thing to keep in mind about this article: Gartner's only MQ that focuses on app development is based around these "low-code" multi-experience development platforms which comprise exclusively commercial vendors rather than any open source technologies.

They simply do not have a perspective on professional engineering trends for app development, so this prediction about low-code is pretty predictable.

So I started my career a little bit later, but one thing I enjoy is reading about old development horror stories, it seems like all of the worst ones start with either/or 'Access Database' and 'Visual Basic'.

I guess my question is it seemed like the last generation of "No more developer tools" failed, because the problem in programming isn't knowing how to code, after all it seems like pretty much anyone can figure out how to write Python in a weekend, but that learning how to work and think like a developer. Thinking of edge cases, determining data flows, what to do in the event of problems, etc.

So from those that have a little bit more experience than me, what was it like in the age of MS Access, Visual Basic, and how do the new low code tools address those?

EDIT:

Also it says that the tech will be built outside of IT, but who is going to end up supporting that?

> what was it like in the age of MS Access, Visual Basic, and how do the new low code tools address those?

What they all have in common, in my experience, is that they make simple things very simple, but difficult things impossible. If you needed to put a form on a user's desktop and capture what they typed into it, VB was the quickest way to do that. If you wanted to make sure they only put valid dates into the date fields and numbers into the numerical fields, you could do that with a click of a button, too. If you had to do any sort of contextual validation or cross-form validation, or long-running workflow or approval or any of the sorts of value that automation actually promises, it took much, much longer to figure out how to force that square peg into that round hole. It could be done, but it was nearly impossible to test, broke for mysterious reasons under real-world conditions, and was noticeably slow (as in, go get a cup of coffee and come back slow) in use.

When I think of "no-code" tools, I think of Salesforce.com, which to me was "Visual Basic for the web". If you wanted to put up a form on a website and capture what the users typed into it, SF made that simple. But anything beyond that, you were going to spend a lot of time fighting with the undocumented parts of the system.

> What they all have in common, in my experience, is that they make simple things very simple, but difficult things impossible.

Exactly that...

I used to work at a company where all kinds of tools where in place, from normally written Code to some web-based Oracle app and even an Access-like solution. The Oracle stuff turned out to hardly work remotely and being extremely inflexible. Eventually the company was split ("un-merged"), so the Oracle app wouldn't need any further customizations. A few months later from the department that used this Access-like solution the lead was fired.

On the other hand much of the properly engineered code survived several mergers and acquisitions.

It's been a long time, but as I recall there were two problems you'd run into with Access:

1. The database you're using was put together as if it were an excel spreadsheet. There was data duplicated between tables but not linked in any meaningful or consistent way, and fields that were supposed to have a fixed set of choices were terribly unnormalized. Think of a column for colors where you have grey, gray, grya, or Gray that are all intended to be the same color, but were entered by differently and wouldn't show up as the same in the reports that were generated. 2. There were real limits of the capabilities of the technology. Performance would drop for a while, but eventually you'd hit hard size limits and have to split your file into multiple "databases".

The first problem is definitely the kind of problem that you you're describing, where you have people working with a technology they aren't trained in.

Workers with these systems had long check lists they would run through to massage the report data into the form they needed, and these check lists would grow as they found more and more edge cases. I used to think it was crazy, but now I realize the alternative when these systems were built was probably post-it notes on a wall. Sure, eventually they had to have someone rebuild their system (move it to a real RDBMS), but meanwhile the business provided it's value.

Visual Basic wasn't a great language as a language, but the VB application was awesome for developing GUIs for code you'd written in a better language (it was dirt-simple to call C or C++ functions from VB components).

The VB UI builder still hasn't been equaled for straightforward ease-of-use, IMO.

Things change over time, including APIs. Most of these low/no-code tools offers integrations, using APIs. You'll get something setup and working and then one day it breaks, because the API for your integration changed. Now What?

Now you wait, without your no-code tool working, while someone that actually writes software gets around to fixing it for you.

We'll have 80% of solutions failing sometimes and no one can that help in a timely manner. We'll see how long these solutions last.

What if you need something the no-code tool cannot do? I've used one where you could add your own formulas, much like you can make formulas in Excel. I don't want to work in a tiny edit box to create a giant nested call in your proprietary formula language. Ever had a bunch of nested if statements in Excel? Its real joy, not.

I just learned this recently. In that formula bar, you can call custom vba functions written in the IDE.

Low-code tools are the "non-alcoholic beer" of the IT industry, they go against the sense of the industry itself, which is not(only) getting drunk, as the case for the beer, but to create overly complex systems that you can make your clients pay millions for.

There are some really good low-code tools. For the most part programmers and IT professionals will use them. We have scene this before, look at the history of Visual Basic for direct comparisons.

Low-code is here to stay. Most business programming should be done outside of IT. Not because programmers will not do it but in order to have better alignment with the business. Programmers will still have jobs and be needed. The work will shift as it has for the last 50 years to higher level languages that use libraries and frameworks that allow fewer programmers to manage more business value.

If businesses could write good specs, they would do so now. For the most part they don't because it is really hard to write good specs.

There is a place for low code like system administration or application configuration. Eventually all end user software will hit boundary conditions because it’s impossible to test for all permutations the moment you go beyond the simplest applications.

What I read is: "80% of IT jobs will now become solving someones convoluted logic in some visual coding tool".

(Of course just like Excel tools like these can also be used in a good way by good people)

First off, disclaimer, co-founder of Lowdefy [0] and shameless plug. But feel ok since it is on topic.

We’ve built many back-office tools for customers and the bulk of the engineering time goes into understanding the problem and tranlating that into data. Tools like Lowdefy make it a lot easier to put this translation into action, but the real work is done by a data literate employee. We believe that role will stay with it the IT / dev department, at least for any project / tool larger than a Airtable. It use to be all tools larger than a spreadsheet or access DB, but now that scale has increased slightly but not much.

For this reason we are designing Lowdefy to be a dev first low-code platform. By writing apps in a DSL you get the following advantages:

- No steep learning curve for new devs :: All devs are familiar with DSLs.

- Apps follow a structured schema :: Easy to pick up where others left off.

- Nothing is hidden in a GUI :: You can copy, paste, find, replace, review changes, duplicate repos, etc.

- Create and manage apps with code :: Develop scripts, like a visual app builder.

- DSL files work with all dev tools :: Devs want to use their favorite tools.

[0] - https://github.com/lowdefy/lowdefy

----

With all this said, you can optimize with tools as much as you like - most dev productivity is always lost in building the wrong things.

About thirty years ago, I went out of my way to stop my company from acquiring another company whose only product was a low-code Motif (as in X Window) code generator. My boss’s boss was very much for the acquisition, and it almost ruined our friendship when I had a long talk with his boss and put a stop to it.

I now have to admit that I more or less agree with this article. I see so much wasted effort in not enabling subject matter experts with tools that would allow them to build systems that might be good enough to just use and maintain as-as, or prove value propositions that trigger expensive conventional development efforts.

I just bought the domain low-code-AI.com that will probably be home to prototypes I have for data prep and deep learning, and simplifying working with internal knowledge graphs (the two things that I have mostly worked in in the last ten years).

I like the comment in the article that application development is becoming a team sport, and not just done by a separate IT department. Much of the real value in corporations is in subject matter experts who believe in the company and nerd-out over the minutiae of running the company. I tend to view software developers as high paid fungible workers, somewhat easier to replace than SMEs.

Excel Macros, and MS Access, and the various website template builders, are the best we have done so far with 'low code tooling' for the average joe.

Anything more complex, it is going to require a good degree of programing knowledge/experience.

I think the next version for low code tool, will look more like Visual Basic, for web/development, that will allow average programmers to get more things done.

But you will still need people with basic programing knowledge, regardless.

As long as shadow IT is allowed to build their business processes using no-code tools there will be plenty of work for expensive consultants to clean up the mess.

If I had a quid for every time during my 20+years of IT experience I've heard that code-generation, low-code, no-code was about to breakthrough, I'd have a private jet on 24-hour standby.

This bit made to laugh:

"“For instance, machine learning features for helping coding are available. One example is Microsoft’s Intellicode,” Kandaswamy told VentureBeat. “While such tools are in their infancy,"

Intellicode has been around for over a decade in Visual Studio!

Few low-code marketing materials seem to mention support for unit testing.

In fact, a few seem to claim that low-code products remove the need for unit tests altogether.

That makes me worry a bit about the stability of the infrastructure that will be introduced when low-code is sold to organizations.

It also gives me a concern that low-code could be a territory and cash grab that does not genuinely care for long-term customer value.

There seems to be a wave of no code hype, much of it coming from the VC community, and I’m baffled as to what has happened to convince people it’s going to work this time. Is there some breakthrough tool I’m not aware of? Or is it just like this article, a bunch of pitch decks saying “if we can take just 80% of the tech market we’ll be zillionaires”?

Besides serious growth, he big low-code companies posted some impressive case-studies.

For example Outsystems's software was used to build a hospital management system, commercially.

So they've got a a lot of deployed software for a few years, and some of it is really complex.

And it seems to work. No huge negative PR AFAIK.

And there's ton of demand.

I do wonder what's they're breakthrough though.

I believe GPT-3 being able to convert descriptions of functions or designs into semi-functional code is what has some excited. It's certainly the strongest argument and reason to hope it could be different this time that I know of. I'm skeptical but come from a generative AI background so I wouldn't underestimate it will be able to do things previously unaccomplished by making templates in the past.

How does GPT-3 differ from a gui based no code tool?

I’ve tried to find that out but dunno. Do you have an idea?

GPT-3 does only thing, predict the next character based on the previous n characters.

The nuance of the context (previous n characters) and the quality of the prediction(s) (following character, a function of gpt-3 you can repeat by just concatenating its last prediction to the previous n characters) is what has significantly improved.

It has now learned on a significant amount of the writing available on the internet. Which includes guides on writing code, stack overflow, and github repos.

So one is able to write something that looks like a python comment

// This function adds two numbers

And the following n character predictions of gpt-3 will with some unreliability spit out the python code for that function as its predictions

def add(x, y): return x+y

This has been shown to work with simple descriptions of pages, with it returning html with css embedded that matches that description.

I had not put these two things together, thank you.

"No code" opens up more purchases direct from the business groups at a company, rather than through a bureaucratic IT department. I am not surprised that it's being pushed hard.

The essence of programming is logical reasoning. The people who are good at that are already programmers, and the people who aren't don't want to be programmers. Code isn't church latin. Attitudes, not the physical act of coding, are what limit people from building their own stuff.

It may be tempting for a programmer to take that view; programmers are the logical ones, and the non-programmers are either too dumb or lacks the right attitude.

I am more sympathetic to non-programmers. They may be logical too, but they just specialized in different fields or hasn't had the time and chance to learn programming. They may as well have in-depth domain knowledge and logic. These people may as well benefit from having low-code tools to further their fields.

Relevant commitstrip: https://www.commitstrip.com/en/2016/08/25/a-very-comprehensi...?

I doubt anyone here on hn will be impacted in any way by such tools. If anything it would be a positive impact as these tools aren't trivial to build.

However it will impact wordpress developer types. I imagine a graph like tool where you drag and drop nodes and link inputs and outputs will make quite a few redundant. Stuff like signup -> confirmation email -> send spam every X days, or order -> get customer data -> get stock availability -> ship -> notify are such common workflows among small shops that i find it hilarious people still pay developers to implement them. Each node can be a call to an internal or external api, a db query or whatnot.

Perhaps a good opportunity for brilliant minds to take on this and _do it right_.

The funny thing is that bubble.io (as one example) does this already. And it does it really well.

And now I look on freelancer.com and there's still people wanting to hire "bubble developers".

I have been talking to my tech illiterate friends what they think about "easy" no-code solutions like WordPress or squarespace.

The answer is always the same. It's all far too complicated and confusing.

If I presented someone like that with bubble.io and said "here is this node graph tool to connect..." I'd have lost them at node graph and they would never, ever learn, let alone like that thing.

Apple famously drive engineers crazy with their UI philosophy of hiding everything at the cost of control or customisation. But I have a feeling it works.

I feel that for many people, tech is this confusing thing that will never not be confusing because they've learned to expect that. At least my friends in their late 20s to 30s have fought with technology all their lives to the point where I don't know if anything can remedy that preset expectation.

So long as these people exist, we as engineers and developers can keep looking at these no-code tools and marvel at how simple things have been made, but I think we have to change our expectations and realise that even the simplest still has to become simpler.

The battle of trying to teach that generation technical concepts is a very hard one, when there are companies falling over each other trying to simplify everything to the point of almost, well, zero-effort? Maybe that's the next step: low-code, then no-code (but some effort involved) and then no-code, no-effort (aka you just sit there passively while a computer reads your brain and works out everything you want)

I say all of this while I'm building a no-code website builder that's looking more and more like it'll be targeting kids, the elderly and luddites, so I've had to do some thinking around this problem space recently.

I enjoy node-red[1], considered low-code. There's a trade off between abstraction and simplicity, I fell that the low code marketing is targeting people that wants to start using the product/services as fast as possible, inpatient to read documentation, or lean a programming language, just want start doing and node red is great for that, if you want quickly prototyping or testing some iot logic.

I used to use low code for create games,as gamemaker, easy to start, but at the end they all look the same and you quickly find that has nothing better than text for dealing with abstraction

[1] https://github.com/node-red/node-red

Somebody’s still going to have to maintain no-code apps. If they do as much as current apps, they’ll be just as complicated as current tech. Seems like that maintenance role will be left to people with system design and debugging skills—i.e. software engineers.

Software engineers don't have a monopoly on system design and debugging skills, not by a long shot.

well if you design IT systems and debug them, you have what skillset?

“ “The barrier to become a technology producer is falling due to low-code and no-code development tools,” Gartner VP Rajesh Kandaswamy told VentureBeat. When asked what kinds of tech products and services these findings apply to, he said “all of them.””

Reminds me of the exchange between Katie Couric and Sarah Palin along the same lines:

COURIC: And when it comes to establishing your world view, I was curious, what newspapers and magazines did you regularly read before you were tapped for this — to stay informed and to understand the world?

PALIN: I’ve read most of them again with a great appreciation for the press, for the media —

COURIC: But what ones specifically? I’m curious.

PALIN: Um, all of them, any of them that have been in front of me over all these years.

COURIC: Can you name any of them?

PALIN: I have a vast variety of sources where we get our news.

Pure marketing spin. Is Gartner just a conduit for Silicon Valley VC money and influence?

You could replace every occurrence of 1991 in this article with 2021, and every occurrence of 2024 with 1994, and it would read exactly like a piece from 1991, and have just as much substance, too.

(Spoiler alert: nope, it didn't happen in 1994, either.)

That is weird argument, just because it didn't happen then, it doesn't happen now? Plenty of tech did not happen the first time around. VR, mobile TV, Electric Cars, Machine Learning, comes to mind.

> That is weird argument, just because it didn't happen then, it doesn't happen now?

If you try to do it the exact same way, without even bothering to look at what happened before, let alone learn any lessons from it, then no, it won't happen now, either.

Is there some technological advancement that has created this most recent low code hype?

I’m certain that there have existed companies who didn’t want to pay programmers for exactly as long as there have existed paid programmers; what’s unique about right now?

I did myself a disservice by bothering to read the article, and it's still a joke.

More powerful tools don't solve the problem that you still need to understand what you are doing and how to achieve that in a way computers do it correctly and reliably. I don't think that entry to software engineering and development is simple. And it might not even be something that most people are capable of.

Yeah, you can show anyone how to mash blocks together, but to have them make something usable and working that can be expanded or changed is much higher barrier.

Same with AI. You still need to define lot of things to get right output for given input. And some of the cases are very complex.

> We’ve all been hearing the hype lately about low-code and no-code platforms.

This is the first sentence of one of these "articles". It's a classic buzzword, just another brand of enterprise software marketing gimmicks.

Anything to keep people from using, say, 3x5 index cards in an innovative way or applying the concepts like RACI matrix outside a computing context, to the organizational structure itself.

This entire ecosystem is fascinating; I highly recommend working in enterprise software for at least 18 months, which is how long I made it before my brain short circuited.

Houses are something that have been built for 1000 of years, we mater the thing. And we have the tool to build them automatically: software, giant printers, etc.

Yet we still don't.

I do think it's possible that softwares will be built more and more by automatic tools (shopify, wix and wordpress are good examples), but 80% is a tad optimistic.

Everybody, they just tell the truth.

80% of "each" tech project could be built outside IT by 2024, thanks to low-code tools

20% of remain tech in each project, we will just hire some IT guys to rebuild everything in high-code skills.

Every time you move code away from one layer, you end up using that to add code on top of it and increase the complexity you can handle. There's no replacement for the drive to make stuff.

True, it's called cobol/fortran/ada/vba/python/exel BUT it's not "low-code", but outside the IT-Bubble.

BTW: Most of the code is written outside "IT"

Did they make up this claim or is this grounded in anything? If so I would love to see a paper on this because this seems like an outrageous claim to me.

Low code tools like Excel and UI builders has existed for many decades now, whatever IT work they can replace has already been replaced.

CSV IS low-code.

Excel spreadsheets massively rely upon (usually tricky, sometimes network-enabled) macros.

I don't understand your comment. Do you disagree with my statement that excel is low code?

No offense but yes. Excel can be any arbitrary code. So it can be arbitrarily big/complex.

2040: all IT projets are about migrating low-code projets from an outdated low-code technology to a new shiny low-code technology.

#Sisyphus

and the new shiny technology is coined very-low-code

People have thought this for decades, yet no tool will ever save you from specifying what it is you want done.

low-code tools help domain experts do amazing things but eventually lack of simple understanding of things like data structures, inferential statistics, etc, always hit back... hard. By the way it’s the same issue with amazing programmers that refuse to empathize with business.

Salesforce's initial marketing slogan was "no code". What year it was, 2010?

Actually it was "No Software"

Put this here to see what the HN community thinks of this trend and the 2024 projection.

Who build the low-code tools and 'add-on' if not IT?

low-code tool might maybe get us back to where we were earlier with VB... but there was a cottage industry of OCX controls, again built by IT.

Same thing is/will happen with 'low code' tools: they all have their internal market, where "IT" sells what can not be done with the low-code tool.

And then, it's like Excel or MsAccess... it works until it does not (or the person who wrote it left the company) and then it needs to be rewritten.

That's a good point though I think most apps are CRUD and ETL and are very repetitive.

Didn't UML and Rational Rose killed the tech industry in 2005 /s

No No No

There is such a thing as software literacy just as there is a thing called literacy. We spend the first 15-20 years of life teaching literacy so that a young person will be productive in life.

What makes us think it's going to be different with software?

The idea of low-code is like the idea of writing a novel by cut and pasting loads of blank comic book panels carefully crafted by Marvel Studios.

This job used to be called Analyst-Programmer - and nothing in low code will stop the analyst part from being needed. As for the programmer part, it is way way easier to express yourself in code once you can code than any of these blocky tools.

Yes we desperately need new and better tools and languages and processes and so on. But not dumbing down - skilling up

Well said.

> But not dumbing down - skilling up

But, you cannot have Wall Street consolidated market winners if you do that! How dare you!

I saw this first hand growing up. The school system had a couple of programming courses a few years before I got into the high school, and then it got all new computers and magically reduced computer education to only a set of Microsoft Office courses offered.

Who needs programming? The school knew we would all only need Word and Excel at any "office job" we could possibly ever get ...

So much this. I was in that beautiful space where schools experimented with CNA and A+ cert programs that set me in the generalized basics of how to escape from proprietary stacks.

Fully agreed.

A former employer once decided to empower non-technical users to design their own integrations using zapier. It was fine until someone wrote an action that changed a cell on a spreadsheet, which triggered another action that, itself, triggered the original action. A more software literate user would likely have noticed the infinite loop. That was not a fun week.

And anyway, this specific case was all to keep two calendars in sync, for which there are simpler and more reliable solutions. Even this awareness, of knowing when to look for something instead of making it yourself, is part of software literacy.

It also strikes me that the hyperfocus on UX that we've seen in the past, say, 20 years, has systematically removed users' ability to gain software literacy the way it was mostly done in the past: by tinkering. Current young users are mostly clueless about the workings of their apps, since their attention is so well held by apps' prescribed interactions.

Agreed - I mean I grew up on a couple of Sinclair's. You literally started in a command line. You needed to load up the distracting game from tape. Magazines had print outs to type in (that was less cool but at least you had he point)

Damn I need to start those coding clubs with my kids ... it's like growing up in a chefs house who just orders take out cos he is too tired after a days work. poor kids

Even the tired chef can still raise their kids with a healthy respect for food and cooking. By all means, order takeout every night if you can afford it, but take that as an opportunity for thoughtful critique: "maybe this meal was too salty because it was counterbalancing the sweetness of the sauce, or maybe the meat was rank and so it was oversalted".

Don't beat yourself up :)

Just be thoughtful and expressive with your kids, and they'll find their own way around software. Just like you did ;)

First off, disclaimer, co-founder of Lowdefy [0] and shameless plug. But feel ok since it is on topic.

I 100% agree with you on this. We’ve built many back-office tools for customers and the bulk of the engineering time goes into understanding the problem and tranlating that into data. Tools like Lowdefy make it a lot easier to put this translation into action, but the real work is done by a data literate employee.

We believe that role will stay with it the IT / dev department, at least for any project / tool larger than a Airtable. It use to be all tools larger than a spreadsheet or access DB, but now that scale has increased slightly but not much.

For this reason we are designing Lowdefy to be a dev first low-code platform. By writing apps in a DSL you get the following advantages:

- No steep learning curve for new devs :: All devs are familiar with DSLs. - Apps follow a structured schema :: Easy to pick up where others left off. - Nothing is hidden in a GUI :: You can copy, paste, find, replace, review changes, duplicate repos, etc. - Create and manage apps with code :: Develop scripts, like a visual app builder. - DSL files work with all dev tools :: Devs want to use their favorite tools.

[0] - https://github.com/lowdefy/lowdefy

----

With all this said, you can optimize with tools as much as you like - most dev productivity is always lost in building the wrong things.

Ok - piqued interest, the DSL sounds interesting and I tried the demo. Wish you all the best

Low-Def-ee or Loader-fi

Thanks :) It's Low-de-fi

A lot of the developers these days tend to be integrators. The no-code tooling can help actually take that procedure to a higher abstraction where understanding of the system would still be needed but understanding of the low level details of coding can be completely eliminated.

Think languages like JS or PHP. World have been built using these and many of the developers in these languages don’t have understanding on how computers actually work. People can built money making code with these without learning about data types. Both are regarded as low quality languages but both are extremely productive.

Also, many people who don’t know any computer languages are programming in MS Excel all the time.

Sometimes, some tools are simply extremely productive and intuitive when the mental model of the domain you are solving problems matches the way these tools work.

You don’t need to know “how computers actually work” to write code in high-level languages. Those are too abstracted away from the hardware and OS.

PHP and JS are not considered low-quality languages. They are low-hanging fruit for amateurs to write low-quality software. Yes, people who don’t really know what they’re doing can make money with PHP and JS, just like people who don’t know about food, cooking, nutrition can run a restaurant. That’s not really a good argument for low-code, though.

JS and PHP are often a joke due to their inconsistencies.

Anyway, these are also low-code languages. They are not low hanging fruits because of the syntax or the features but because of the API and boilerplate geared towards specific domain. These almost get out of the way of the people who are not fascinated by the technology itself but by the product they are building.

It’s so easy to use JS and PHP to solve a problem.

For PHP, you simply wrote your code and put in a folder in a LAMP machine and it works.

JS is even easier, you open the developer tools in your favorite browser and there you have it. Instantly start working on your idea.

I’m not unfamiliar with PHP and JS. Those account for about 90% of my work, and have for over a decade.

Every language has its inconsistencies. No question PHP and JS have their faults. That’s what happens when a language gets popular (i.e. actually used rather than just argued about in programmer forums) and the deployed code base grows faster than the developers can “fix” the language. Back-compatibility then imposes real constraints. This happened with C, C++, and SQL too, and every language people actually use to write code with any value. The only joke is smug programmers not getting that we can’t go back in time and fix problems obvious in hindsight unless we’re writing class assignments or hobby projects in Haskell.

I make a good living maintaining and rewriting the first drafts of PHP and JS code written by people who let a bit too much get out of their way. Usually they run into problems of scale, security, maintainability.

If you think deploying a real app that has business value amounts to dropping some PHP files in a folder you should keep my email for when that doesn’t work out. I hope the ransomware hackers don’t find your code first.

I don’t see why you are offended. I love JS but here it is 20min of programming jokes in the expense of JS: https://youtu.be/et8xNAc2ic8

As it comes to PHP, I don’t say that you can do everything by a single PHP file in a web server folder(actually, you can but not comfortably). I’m trying to illustrate it’s low-code nature.

There are no other languages that are that easy to start solving your problem with. Okay, maybe Python.

The newer no-code or low-code tools have the same spirit. They are abstraction layers targeting a domain.

These days there’s plenty you can do by programming visually without any knowledge of programming languages. Not everything needs to scale for throughput.

I’m not offended, I have no investment in those languages, or any language. I just don’t agree.

PHP is easy for beginners because of the tooling, or lack of. As you wrote you can just put PHP files in the right folder and there’s your “Hello, world” web page. The language itself is no less capable and sophisticated than any other C-family language, and PHP’s huge (and inconsistent) standard library goes a long way. But getting a demo or tutorial page up is not software development. You have to write actual code to make even a simple CRUD app, plus understand something about databases. It’s not low code.

You can maybe learn JS in the browser console but that’s not developing anything useful. To run JS on the server you need node and npm and the skills to get that all working. Not low code either.

These are low bar to entry languages/ecosystems but they are not low code/no code solutions.

still, the sheer number of ready made sandboxes certainly will expand such that niche software implementations will be far and fewer.

of course, like moores law, its likely not going to engulf everywhere a programmer touches, so new use cases will keep busy.

but take wordpress, you can basicslly build a whole ecommerce site knowing a couple of plugins real well.

By 2024? You have to be kidding me.

2042

Not then either.

CRUD yes, algorithms no

100% this won’t happen, and certainly not by 2024.

By 2024, enterprises won’t even have them on their radar.

They already do, most ERPs or CRMs are partly made/customised from some sort of version of lowcode soup (eg dynamics, salesforce).

Those are low code as long as you can change your business requirements to match what the tools can do. SalesForce requires expensive consultants and developers to do anything beyond basic contact management.

This is known as shadow IT. And it is a risk for any big corporation.

Are you going to leave to "users" to implement GDPR and other regulatory compliance? No, that would be too risky.

"low-code tools" seems misleading.

On the other hand, I agree that if you think that data-scientists are not tech people. There is going to be a big increase on non-tech people (data-scientists) working in IT. But this is more a definition problem that any fundamental change.

haha no

Was this post removed from the frontpage because of it's title starting with a number?? Can’t we change the title?

It set off the flamewar detector. The thread is better than that, though, so I've turned that off. More here: https://news.ycombinator.com/item?id=27511358

Regardless of the 80% number, it feels a right discussion to have. Technology is becoming simpler every year, allowing to do things today than only developers could do 10-20 years ago.

They also said we'd be living on the moon by the year 2000

I had a university professor with the same near term horizon stating this in 2006. If it wasn't a mandatory class I would have dropped it right then

Funny. I was told at a serious tech trends seminar in 1981 that programmers would go mostly extinct by 1984 because of automatic code generation tools. Glad I didn’t quit back then.

I think this is just a meme sold to CEOs for a long time. Maybe we can go further back.

COBOL. The design goal of COBOL was literally to make professional programmers unnecessary.

"Hi. We built a website with lowcode tool X, and would like to extend it with premium feature Y, Z and W without having to pay for it. Can someone who knows a bit of technology please volunteer help us extend the locked-down functionality and break any license agreements. We pwomise you won't become our fall guy, and will evict you off the project as soon as you're done."

We actually hear these things for reals.

Reply on news.ycombinator.com