4 ms·

I must be part of the dying breed too. Having been involved in migrating very broken Excel/Access/VBA into properly formed web applications for companies I've w

I must be part of the dying breed too. Having been involved in migrating very broken Excel/Access/VBA into properly formed web applications for companies I've worked at, the problem is people using the wrong tool in the first place. It may meet their immediate need but with no viewpoint on it's future usage, then fragility sets in and it costs the company more in upkeep and resource. I can see how that happens, but perpetuating it seems a bad idea.

pacoWebConsult 7y ago
Worked on a project last winter to add a fully featured compliance management system to a state regulatory agency in Access. They have moved to a sql server backend but the support for database operations is incredibly limited by the Access JET DB engine. Ended up just using ADO in my VBA scripts for everything instead of the Access database tools because it was not capable enough for the complexity. This client doesn't have the budget to migrate from Access, but has the budget to continue slapping garbage to it every year. At least as the primary NGO involved works with other states to create a web-based solution, my client might be able to move away from Access by 2025? I would say the majority of orgs that encounter this really have no choice in perpetuating the use of bad systems.
fauigerzigerk 7y ago
Looking at it from the perspective of a developer tasked with making a proper app from a spreadsheet, you're bound to come to that conclusion. But that's with the benefit of hindsight and with a massive dose of survivorship bias. Of all the spreadsheets that start out exactly like the ones that need to be converted to an app, how many were thrown away having served their temporary purpose just fine? How many of them never outgrow the immediate needs and skills of its creator? Perhaps spreadsheets should be seen as tools for business process prototyping. Starting a proper software engineering project only after a task has outgrown its spreadsheet based implementation may be a pretty efficient approach.
bradknowles 7y ago
Maslow's Hammer in action.

pacoWebConsult 7y ago

Worked on a project last winter to add a fully featured compliance management system to a state regulatory agency in Access. They have moved to a sql server backend but the support for database operations is incredibly limited by the Access JET DB engine. Ended up just using ADO in my VBA scripts for everything instead of the Access database tools because it was not capable enough for the complexity. This client doesn't have the budget to migrate from Access, but has the budget to continue slapping garbage to it every year. At least as the primary NGO involved works with other states to create a web-based solution, my client might be able to move away from Access by 2025? I would say the majority of orgs that encounter this really have no choice in perpetuating the use of bad systems.

fauigerzigerk 7y ago

Looking at it from the perspective of a developer tasked with making a proper app from a spreadsheet, you're bound to come to that conclusion. But that's with the benefit of hindsight and with a massive dose of survivorship bias. Of all the spreadsheets that start out exactly like the ones that need to be converted to an app, how many were thrown away having served their temporary purpose just fine? How many of them never outgrow the immediate needs and skills of its creator? Perhaps spreadsheets should be seen as tools for business process prototyping. Starting a proper software engineering project only after a task has outgrown its spreadsheet based implementation may be a pretty efficient approach.

bradknowles 7y ago

Maslow's Hammer in action.