Knowing I was a data engineer, one of the archaeologists asked me to take a look at the cataloging system he’d cobbled together on his own: a shared-drive Access database with a full-featured CRUD interface that the whole office had been using for years.
I was able to clean up one stray bug he had, and confirm his suspicion that one particular action was running slow because it had to touch multiple files by necessity (he’d rolled his own sharding) — but generally speaking, it was a work of art more effective than anything I could’ve ever come up with. Sometimes the “dirty hacks” are the best solutions.
But I have seen the maintenance burden first hand of solving weird Access lock file problems (if I never have to manually find and delete an .LDB file again, that would be great) and silent corruption issues and more. I've seen the workarounds of auto-backups of the shared folder and then auto-restores of those backups when silly things happen like the .MDB file is not the expected file size.
There's a special "joy" in needing to know the many under-the-hood versions of Access files and seeing apps that consume and/or produce more than one version at a time. That's just to maintain existing "apps", trying to migrate that data to modern databases for new apps is its own "joy" as well.
I ended up building an Access app at an enterprise-y company I used to work at because it would have taken years for IT to build it. The app did something super specific and kept needing super specific additional features, and there wasn't anything on the market that met our needs. The Access UI talked to another Access database on a shared network drive. I just found out that it's still being used heavily by several people every day, 17 years later. You pretty much nailed it, Access is hacky, but it works!
Edit: grammar