I agree, but at the same time, people who cry out against flimsy VBA scripts and Power-BI disasters pretend to ignore how f-ing hard it is to get a properly executed business automation project off the ground.
These things start when a domain expert finds a way to get something done in their cube using macros or scripts. This tends to grow and grow the more successful it becomes. And yes, it becomes a mess at some point from a software-engineering perspective.
These domain experts would very much like to "do things right" but they lack the leverage to make it happen. They are not in a software development department, they're surrounded by bean-counters, administrative battle-axes and people who would be perfectly happy to continue doing their work "the stupid way" until retirement. It's really, really difficult to propose something new in an environment like that. It involves change, which is intrinsically opposed in many business departments. Moreover, if it does get to the point of hiring a consultant, they [the consultants] are not going to lift a finger for anything less than 10K for even the simplest of projects. There's a threshold that needs to be crossed before the right executive takes action and by that time, the project is huge, complex, risky and most importantly a completely unplanned-for and unbudgeted surprise.
> These domain experts would very much like to "do things right" but they lack the leverage to make it happen.
The reality could be worse though. My experience is that many domain experts refuse to "do things right" from a software development perspective. Many domain experts think their code is good enough as long as the code get correct results. Unfortunately, domain experts in general are terrible coders.
They may not know how to do it right, nor have the means to get a software development team started on the project. To some extent, "if it works, don't fix it" applies here... until it doesn't work.
I don't blame domain experts for scratching their itch and solving problems in whatever way they see fit using their own knowledge and tools. It's the way that many software projects get started, and where new opportunities get discovered. These are good things.
These things start when a domain expert finds a way to get something done in their cube using macros or scripts. This tends to grow and grow the more successful it becomes. And yes, it becomes a mess at some point from a software-engineering perspective.
These domain experts would very much like to "do things right" but they lack the leverage to make it happen. They are not in a software development department, they're surrounded by bean-counters, administrative battle-axes and people who would be perfectly happy to continue doing their work "the stupid way" until retirement. It's really, really difficult to propose something new in an environment like that. It involves change, which is intrinsically opposed in many business departments. Moreover, if it does get to the point of hiring a consultant, they [the consultants] are not going to lift a finger for anything less than 10K for even the simplest of projects. There's a threshold that needs to be crossed before the right executive takes action and by that time, the project is huge, complex, risky and most importantly a completely unplanned-for and unbudgeted surprise.