[weitendorf]

Sufficiently advanced "low code" is indistinguishable from a framework or a library.

The main difference in practice is that most software that markets itself as "low code" obscures how it works and tries to lock you in to charge rent. Though to be fair, there is generally not much of a market for proprietary/non-OSS libraries and frameworks anymore, so if you want to monetize your library/framework low-code (or an API) is probably the way to do it.

Aside from that, I do think the "low code" label can be genuinely helpful as a way of communicating towards semi-technical users that the software they're using is intended to be usable with their level of technical sophistication. IMO this has been a perpetually underserved market, and it's growing over time especially as computer science/programming gains popularity in schools. There are a lot of people out there who understand basic programming and took maybe a couple CS classes in their life, and want to do something entrepreneurial or practical for their non-SWE jobs, but aren't skilled enough to dive right in to doing things the way experienced SWEs would do it.

[threatofrain]

This makes me think about Microsoft Access and why it never took off. It helps people create databases, forms, and reports. One might call it a no code solution as opposed to merely a low code solution. There are a lot of businesses that's ostensibly in the right place for Microsoft Access.

In my view there are certain aspects of app building that's hard. Some of it is in code, some of it is in design, some of it is in domain modeling. Every once and awhile you get stuck and your low-code solution is suddenly paralyzed at that one point. ChatGPT unblocks you until you REALLY need a programmer.

Low or no code did not make sense until ChatGPT.

[andyferris]

Access was more popular with a certain crowd, way back.

Then the client-server world dominated the desktop, plus we needed automated backups and source control and tests and scalability and auditing and hosting and security and other really important things that never properly made there way into Access. Presumably Microsoft didn't want to cannabilize SQL Server sales and chose not to invest in those things that would have actually made it an MVP for building home-grown apps.

[unscaled]

Microsoft Access definitely took off. It was certainly more popular than the new crop of no-code/low-code platforms we have today. In the late-90s and early 2000s almost every large company seems to have had Access applications running in several different corners of the business.

The reason Access eventually died off is that it wasn't designed as a multi-user database. You could run Access on a network file share but performance would suffer (especially with concurrent access by multiple users), and you'll be running the risk of database file corruption. Microsoft Access did support a client-only mode, where Access is used for the forms, queries and application code, but the actual data is stored in Microsoft SQL Server — but setting up and maintaining a database server was probably too complicated for the type of contexts in which Access became popular.

The key point is that most of the usage of low-code products in the past was basically an instance of Shadow IT. In order for a Shadow IT product to be successful it generally needs to be easy to use, easy to distribute (or access) and have a capable free (or effectively free) version. Access and Excel had it all. They were easy to use for beginners (although complex applications required skill). Distribution was extremely simple in the corporate intranet age: you just had to place your Excel or Access file on a network share. They were part of Microsoft Office, so everybody had them on their computer "for free". If a product fulfills the conditions above, entrepreneurial employees will start using this product to address viable needs that your IT department lacks the resources to solve with a more robust solution.

Often these Access apps became popular enough that it had to be officially taken by the IT department, where IT programmers invariably cursed the buggy hack of an application they had to maintain. I don't know the statistics, but I assume a great number of these would just be rewritten as a traditional client/server or web application.

[slfnflctd]

> it wasn't designed as a multi-user database. You could run Access on a network file share but performance would suffer [...] Access did support a client-only mode, where Access is used for the forms, queries and application code, but the actual data is stored in Microsoft SQL Server

Both your comment and a sibling's mention features that Access either didn't have or didn't do well. However, there were low-code/scripting workarounds for all of these, which were in fact used in many places. It was scalable if you were just knowledgeable and persistent enough to keep chasing your goals. In addition, the backend didn't have to be SQL Server, it could just be another Access database.

I myself created a 'sharded' Access-only implementation (admittedly a fairly simplistic one) that supported over 300 concurrent users. The trick was to keep record locking to a minimum by training users to click a 'save record' button when they were done filling out a form (which defaulted to an offline state)-- all the data was then uploaded to the central database in a few milliseconds, and the connection was immediately closed. Kind of mimicking old webforms. It worked.

> IT programmers invariably cursed the buggy hack of an application they had to maintain

This was really the biggest problem. Only apps designed by people who were pretty good at what they were doing avoided this.

[singpolyma3]

Access was so good. I've been trying to find something half as good for years since it died.

[weitendorf]

Access maybe never took off, but wasn't Visual Basic super popular at one point? I think you could arguably call it low-code given its use of a WISYWIG UI builder and eliminating a lot of the boilerplate of creating a windows application. I definitely think you could call Excel a low-code tool too. Probably SAP and Salesforce as well.

I'd argue that it was Cloud and improved monetization opportunities rather than ChatGPT which made the current iteration of low/no-code more popular, although ChatGPT certainly helps (I'd argue that past a certain level of complexity/code sized, LLMs also stop working properly). Most low/no-code tools include hosting, which is a must for anything meant to be served on the Internet, and before public cloud took off, this was a lot more complicated to offer for free or a low-cost. There's also a much bigger market for SaaS and it's easy to take payments over the Internet now, which incentivizes semi-technical to build software to be served over the Internet rather than their desktop (and also makes it easier to build the low/no-code tools themselves).

> until you REALLY need a programmer

This is the thing I was getting at, there are a lot of people who know how to program but are not super-skilled at it, and I think a lot of software engineers don't get this. Think back to when you were just learning to program and how frustrating it probably was to do "basic" things like set up your dev environment or ship a website for the first time. For the people using low-code, it's not that they can't do these things, it's that they'd have to spend a lot of time looking things up and learning how do it, which is a major time investment (and frankly require a lot of persistence/patience which I think professional SWEs self-select for, because the learning SWE learning curve is brutal for most people) that they'd rather not make. You can argue that past a certain degree of complexity that the investment is worth it, but in many cases it probably isn't, and in others it's possible they'd not have made it to the point of outgrowing low-code at all if they had to do everything from scratch.

It's not much different from how we as programmers use things like Cloudflare or AWS Lambda. Could we run and manage our own DNS or scaling? If we really need to learn it, we probably could if we set our minds to it. Is it possible we could outgrow those tools if we start on them? Definitely. But even when we know how to implement our own scaling or DNS we might still reach for these tools just because they're so convenient to get something working quickly, and most of the time we don't outgrow them anyway. Low-code is pretty much the same thing except it has a lower technical barrier to entry (eg you don't need to know how building/deploying software works) and often is easier to outgrow.