[scandox]

One of the things several colleagues have said to me over the years is that Access tended to be a dangerous tool in a large organisation: like Excel but on crack.

You end up with a large number of autonomous, undocumented systems built on an ad-hoc basis by personnel who were often not even in a technical role.

Personally I think that sounds like a great way to leverage the domain expertise of lots of different employees...but I guess it can become unwieldy. I know I saw some amazing things built with Access back in the day...

[hiharryhere]

I used to work at JPMorgan. We had an official acronym for these tools... UDTs, or User Developed Tools.

They initially started when ops teams were told a custom report for a client would be too expensive/slow to build properly by tech, so they would DIY a report in excel.

These started to get out of hand, and after a few years they numbered in thousands and had evolved from excel sheets with macros into full fledged Access DBs with ODBC connections into our data warehouse. A specialist team was created in Ops to build and support ever more complex UDTs, they were called the UDT Team.

Problem was that these were poorly documented and often done without consultation with Tech, so we would unknowingly break loads of downstream stuff whenever we embarked on new projects of our own.

Fun times. Plenty of stories.

[exelius]

You also end up with a mess of VBScript code that isn't versioned. When something breaks and someone calls IT, it really helps if IT knows the system exists.

In a large organization, supporting disjointed business processes (or worse, fragile amateurish integrations) costs more than the software. At scale, consistency matters more than performance variance in some areas.

Access is also a nightmare from a security standpoint. AFAIK that's why it was abandoned; there was no way to keep the functionality and easy defaults that users liked while making it secure. It scares companies shitless to have critical financial data sitting in Access databases...

[vram22]

>You also end up with a mess of VBScript code that isn't versioned. When something breaks and someone calls IT, it really helps if IT knows the system exists.

This is one reason why (I guess) largish companies even have or create apps to manage other apps - like an app to manage (as in know about, not really manage as in monitor) all the other apps in the company. Like a list of apps app. Initially I wondered whether it was overkill but later realized that at that scale, such automation can be useful. But I guess it can go to the other extreme too and become a time sink.

[crispyambulance]

Yeah, but these things exist because they started as experiments which did not warrant getting a team of developers to burn through a million dollars for the first version.

Its really hard to know, in advance, which internal applications are worthy of a development team. As for nightmares... there's plenty to go around for everyone. Some of the worst nightmares are created by large teams of highly paid and skilled developers.

[scandox]

> Some of the worst nightmares are created by large teams of highly paid and skilled developers.

Sticking that above my desk

[sharemywin]

but none if it is easily integrated. you get a lot of data silos. don't get me wrong SQL server has that issue to. a lot of department apps that don't work well easily.

[madmulita]

Over here we call those "clandestine Data Centers".