@srtcd424 It was the lack of any kind of sensible concurrency control that I particularly remember. Two in-house apps could connect to an Access DB, while a third person was editing it directly in the app. And you'd get some behaviour, but good luck reasoning about what it was.
@david_chisnall Hard to tell. A lot of that stuff got outsourced to SaaS offerings when it was sufficiently generic and the vendor convinced client that it
was infinitely customizable. But who knows what's hiding under the hood of a lot corporate IT and how much is properly developed and how much is crap? 🤷♂️
@david_chisnall if its changed itll be because "tech" has swallowed normal firms.
Is the book part of amazon a book seller with an internal software team?
Banks?
I am not in a software firm, i have friends doing tech in non software firms. I think the scale of the tech department in them helps prevent this. Mostly theyre so big now you do get more professional results.
That said, the complexity of modern webdev (not my area) is so high it might be worse than your example in many ways.
@david_chisnall I'm responsible for a few horrors that used Access over ODBC, definitely. Weirdly, the Jet engine itself in those days wasn't horrific - the closest thing to sqlite in that era.
@srtcd424 It was the lack of any kind of sensible concurrency control that I particularly remember. Two in-house apps could connect to an Access DB, while a third person was editing it directly in the app. And you'd get some behaviour, but good luck reasoning about what it was.
@david_chisnall oh, definitely, yeah. I mostly tended to create mildly cursed "intranet" apps that funnelled everything back to a single server, which mostly handled that.
@david_chisnall Also terrifying is spreadsheets "written" by people like accountants rather than professional software engineers. Like, even if it works, which version on which laptop is the "real" version which should be relied on for tracking a multi-million budget?
