> Now it's a 1500 line kludge and they want to unload it, ie pass it over to development for maintenance.
... and THAT should be considered a GOOD THING!
It means you've got a tried and true business case for the application, the requirements capture has already been done, you've got an instant user-base and a very clear bar to jump over. Of course, the application must be able to outperform the old application in every way, or else questions will be raised.
I think it's important to point out that the inception of these excel VBA monstrosities is innocent and pragmatic. An SME has a job to do, they're doing their job, but have a need for a custom tool to help do their job.
It is ALMOST NEVER the case that they should drop what they're doing and engage a SW development team to go through a lengthy VERY expensive process with uncertain outcomes-- all the while still having to do their job. It's much more pragmatic, in many cases, to tackle the problem piece by piece, as need arises, with little spreadsheets, scripts and little databases.
I think complaining about VBA monstrosities is wrong-headed. They should be, in a way, embraced as a starting point for devs-- hopefully BEFORE they become mission-critical to the company, however.
You are absolutely right that the VBA prototype should be seen as a blessing. But no matter how you approach an IT development request - upfront or after the VBA prototype is created - the problem is always the same. IT wants a very, very long time to create something, or allow for the slightest change once created. And lots and lots of emails and meetings before any functionality even might become available (of course, complete failure is a very real possibility).
There is no way for the IT customer to negotiate this "correctly". It always leads to the same result.
The problem is IT exists to administer computer systems, not to help business people create or maintain software. This brings the wrong mentality and skillset.
What my old team did (at a major Fortune 100 no less) was a bit unconventional.
They embedded a technical developer into a business team, and had that individual write the "kludgy" business apps that needed quick automation for throwaway tasks or for data processing standup. The dev has access to more than VBA, specifically, Python, GitHub, the ability to spin up what amounts to VPS's in the cloud with access to all of the database infra. All tools are shared with the rest of the company through a tech sharing program that is being heavily promoted across teams, and of course hosted in a repo, often with docs or a website if possible.
This "fills the gap" of dev latency for small dev tasks that don't necessitate pulling in an entire IT team. I don't really understand why this isn't more popular. The business team this individual was hired onto was over-the-moon when this occurred because they were doing absurd things like copy-pasting and hand-modifying JSON payloads many times a day and simply lacked the skillset to fix the problem, due to the issues you described. These issues were immediately resolved in under a month for hundreds of man-hours saved.
Just give business teams a tech resource that's well-trained and understands proper dev for on-demand work that doesn't justify the agile scrum whatever nonsense, and you won't end up with a forest of Excel macros.
... and THAT should be considered a GOOD THING!
It means you've got a tried and true business case for the application, the requirements capture has already been done, you've got an instant user-base and a very clear bar to jump over. Of course, the application must be able to outperform the old application in every way, or else questions will be raised.
I think it's important to point out that the inception of these excel VBA monstrosities is innocent and pragmatic. An SME has a job to do, they're doing their job, but have a need for a custom tool to help do their job.
It is ALMOST NEVER the case that they should drop what they're doing and engage a SW development team to go through a lengthy VERY expensive process with uncertain outcomes-- all the while still having to do their job. It's much more pragmatic, in many cases, to tackle the problem piece by piece, as need arises, with little spreadsheets, scripts and little databases.
I think complaining about VBA monstrosities is wrong-headed. They should be, in a way, embraced as a starting point for devs-- hopefully BEFORE they become mission-critical to the company, however.