edit: And if that sounds easy, imagine how you would go about upgrading and patching and extending your access-like cloud platform twice a year without any significant breakage of any of your customers varied and extensive customisations, and without any significant downtime, and keep that up for 20 years. Thats the thing that Salesforce are good at, and not many people appreciate how difficult it is.
SalesForce, on the other hand, seems to be more a platform-as-a-service targeted at the user with aspects such as SOQL instead feeling like a bolt-on to give developers access to the data.
So while they fill the same business case, they approach it from a completely opposite perspective.
(Source: software engineer that had to work with SalesForce and other CRM tools extensively while working with data engineers; and that has worked with pre-dotNet ASP + MS Access)
Salesforce seems like a particularly bad solution, you end up with a small army of high priced, low skilled salesforce contractors and a heap of vendor lock in.
I loathe Workday. Performance reviews and taking time off have unneeded steps and comments in weird places. The flat and colorful UI looks nice but it’s hard to find stuff.
The nasty forms are always a result of internal politics and bad governance. One client that I worked with had 8 different ways to represent a physical location. Each operational director in the organization had a unique system, and nobody mapped them.
If you put a real development team on the platform and the leadership gets it, it's an amazing tool.
Which, as you might imagine, resulted in a huge number of multiple choice, similarly-named properties, with all options also being inscrutablely named.
Long story short: programmers are terrible at UX.
Talk about a rapid design tool of both forms and reports (and schema), Access was tough to beat. I think Corel/WordPerfect had a similar concept as well.
Good times.
My manager was a huge fan of Progress, such that it became the de facto tool of choice whether it fit or not.
I was less of a fan, but just checking now, it still exists! I'm curious about this one blurb from their web site though, which proclaims, "Progress Named a ‘Strong Performer’ in The Forrester Wave™: Low-Code Development Platforms For AD&D Professionals, Q1 2019"
I'm not sure how a database applies to sitting around with dice and figurines, but I've never really understood that whole pro gamer thing.
I'd really appreciate HN's feedback on this -- if anybody has thoughts -- I'd love to hear them! I'm also david@ if you'd rather email me anything. Thanks!
Access (and to a lesser extent, Excel) empower anyone to model their data and manipulate it without asking permission. The problem is they don’t scale well, there are no backups, they don’t show up in a data catalog anywhere, no integration with enterprise SSO, etc. They do benefit from file-focused solutions for these issues (eg the Access file lives on a network drive which is backed up) but they fall far short from what you expect from a production database.
So my challenge is: how can I let anyone in my organization create a new database, with all the backup/authentication/discovery/scalability out of the box, for them to connect to Retool?
I was able to build a CRUD app with 20 concurrent users in a month just using a shared directory to host the backend database.
It would have taken a team of engineers 6 months to do the same properly developing a Java web app with Oracle database.
Access does have such easy WYSIWYG reporting tools that I still miss.
We lost something in the switch from "workgroup" (dBase thru Paradox) to client/server.
Spoiler: ODBC broke the tight coupling of code and persistence. Spawning monstrous hacks like ORMs and ActiveRecord. What Ted Neward famously called The Vietnam of Computer Science.
It took me a very long time to figure out what went wrong. Even longer to fix it.
Cliff hanger, I know. Someday I'll post polish and publish that fix. Using my real name.
Access was created to compete with and replace those single-user and workgroup dBase-era software solutions from the 80's and early 90's. It helped them to cover the bases of the 'professional' desktop use cases as they won people over with Windows. With that mission complete and all competitors long gone, Microsoft now needs to kill off Access to get more people migrated over to SQL Server solutions which will allow them to extract more value from their customer base.
And you're essentially saying that this is already another order of magnitude worse than what came before Microsoft. Now I wish I was able to see that older software in action.
If history is any guide, the mobile spreadsheet will never do some (probably much) of what the desktop version did[1] and the desktop version will never get some of the new capabilities of the mobile version[2]... yet over time the less capable, but 'better', mobile app will become the new normal for many. The good news is the mobile version will still be more powerful than whatever platform comes next.
I'm greatly over-simplifying and glossing over some things (esp. re: the dynamics of the text UI and early GUI eras) but I think the basic idea still holds.
[1] It's 'good enough' for the majority of use cases. Some would argue that the lost features were cruft anyway. Which is fine unless you needed that cruft...
[2] The profit motive is no longer strong enough to warrant the needed investment in structural changes to the desktop application
I don't like that "good enough" argument, because it misses the fact that features shape use patterns. Features are enablers.
To give a random example: I once visited my wife's office, and was given a task I could help them with while waiting. It was a task they did very frequently, and it boiled down to specifying a search query, and then adjusting some data in each of the result. They thought it'll keep me occupied for an hour or two, manually adjusting each of the hundreds of results, but I looked around the software and found a way to do a bulk update hidden somewhere in the UI, and was done in 3 minutes.
I taught the people in that office the trick and they were grateful, but it made me wonder - what if one day the software vendor removes bulk update switch because it's rarely used? It's only rarely used because it's not easily discoverable (but the telemetry will not tell you that). Wondering even further - how much money and opportunity to growth do companies lose on office tasks that are inefficient only because software was developed for the lowest common denominator, and offers no advanced features and no path to mastery?
Here I'm only commenting on the impedance mismatch between code (biz logic) and persistence (eg RDBMS) introduced with ODBC. (Specifically, type information in the db schema is lost to the client code.)
Okay, writing this out now, Microsoft (and everyone else), probably didn't appreciate what was lost with ODBC, so didn't consider how to continue the Access style of CRUD to client/server. So we ended up with nonsense like LINQ.
Netbeans with Swing UI designer and database bean components.
You also have to deal with DBAs who like to say no and permissions every time you have to make a change.
Even if you broke down all the bureaucratic barriers, Access is still quicker to make a simple to make a simple CRUD UI than Java swing.
Sometimes worse is better.
Not saying I would use Access today but that is because I became a software engineer who has more authority to use the proper tools. When I started out as an data analyst, Access was the only thing available I had to get the job done and it did it well.
I have experience with both and the NetBeans UI designer is hardly much different.
Now if we compare languages, Basic dialects win hands down for such scenarios.
Reminds me of Airtable, Monday, Notion or one of these all-purpose productivity tools
For heavy stuff, I'll take Postgres anyday given the choice, but Airtable is great for small user-maintainable tools + dashboards, etc
I think there are also some very low limits to the number rows/columns you are allowed to use?
I'm not really sure - honestly asking...
I don't know what the actual market [that will pay money] is for it, but I can certainly say I've never seen anything quite like it.
In high school, I worked as a sysadmin/misc. programmer for a company whose whole business was software built on top of Access. I was the weird Linux person who ended up having to do a lot of stuff in Access (97).
It had its issues. It was not perfect. But the simplicity with which you could bind a visual tool and query designer to an ODBC/SQL backend--I think--goes unmatched 'til this day.
There are many things I cram in a spreadsheet these days that would be way more flexible if they were instead built on a quick and dirty Access DB.
If there are equivalent tools out there, please, let me know.
You could be describing myself. However... I beg to differ on it's scalability... There were 'issues' with the 2.0 Jet engine when accessing MDB files on network shares that would often result in 'missing data'. Lots of fun. (Lots of work up-sizing to actual SQL back-ends as well though)
Once I started learning SQL server and VB5 for real client server apps I never looked back, but then you had to go find a reporting engine too.
Lotus Approach also did the same as Access.
Years ago I worked for a company that claimed to have largest Filemaker Pro database in the southern hemisphere. One day there was some sort of disk issue and filemaker silently failed, then for months it kept pretending that everything was fine, it just wasn't writing to disk. This lasted until a power outage one day when the company discovered it had lost months of customer data, no backups of course, the backup system was working fine but there was no new information being written.
Data loss isn't forgivable, especially in the non-technical user space that filemaker is aiming for.
I'd be interested in knowing who the company was, and the metric they used to judge their database size. I worked on one that was 4GB data and >40GB binary files (photos, documents). Interestingly, when all the data was removed and the file was optimised it came to less than 2MB.
I guess I'm talking about a cultural difference. It's been my experience that Access devs know when a problem is mismatched for Access (and move to storing data in SQL Server, etc). FileMaker devs seem to press on even when it's clear that the platform isn't capable of supporting their needs.
As one anecdote (of several): I support an instance of a FileMaker application w/ several 500MB+ "FMP" files, each of which take _hours_ to "integrity check" when the "FileMaker Server" process crashes unexpectedly. We talked to the dev about putting at least some of the data into an RDBMS (MSSQL, Postgres, etc) and they scoffed at the idea. It simply didn't occur to their mind that the platform might not be a good fit for the purpose.
Had Microsoft gone for a more custom interface like Filemaker instead of just nicely packaging up more general tools, my entire life might be very different and probably not better, even 15 years after having touched Access for the last time.
Printable reports is so 90's. Back then you printed reports and shared reports on paper. In meetings everyone gets a printed copy of the report. Today web is the way to share reports, and you project reports on to a big screen in meetings.
Access is like a cockroach. It never dies as long as some Microsoft stuff is still around. The only thing that will kill it is subscription licensing -- Microsoft eventually take it away for Azure AirTableClone.
I use it as my own version of Shadow IT for my wife's business when im just too time constrained to make her proper web apps to do stuff, and she's too reluctant to spend any money on things, I just whip up a solution in Airtable. She has a CRM I made her for managing her students and their balances. Works well and was super fast to put together.
It's pretty crazy capable as Airtable has various kinds of built in functions for math and string manipulation, plus it can do various kinds of relations, joins, aggregates and rollups. Heck the resulting table even exposes an API!
The only thing I can't really seem to do is business rule validation stuff that a typical CRUD app would contain.
Later, I realised that it had a Y2K bug in it, but oh well.
It was actually amazing how far it could scale, you could put a shared MDB file out on a Novell network share and have 30 concurrent users with no server app at all, users just doubled clicked the MDB.
I still think there is a killing to made on a modern day Access "Done Right". DB, Gui framework and printable report generator all in one sharing the same language front to back, top to bottom.