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