[toolslive]

I've seen the following at least twice: some department manager (marketeers typically have a nack for this) needs something, can't or won't bother the development team and starts off with "how difficult can it be" and before you know it they've written a few hundred lines of VBA, which serves their needs.

But then, the next phase starts: that scripts gets copied over (because Jim wanted to run it too) and modified (Jane has a different VBA version) and expanded (now it does "THIS!" too).

Now it's a 1500 line kludge and they want to unload it, ie pass it over to development for maintenance.

[crispyambulance]

> 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.

[civilized]

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.

[firewolf34]

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.

[liotier]

Look at it another way: that script kludge is a prototype, a dangerous one of course, that embodies the functional requirement better than what the user could express. Understand its deep meaning (what the user meant to do and and not what they settled on considering their technical limitations) and you are ready to rewrite it into a proper implementation. We frequently stumbled upon this situations and we like them, because a well used kludge that reaches its breaking point has buy-in from all stakeholders for a well-budgeted industrialization !

[julian_t]

Oh yes, been there and seen that. Guys on a trading desk at Some Bank wanted an app, so the IT Dept said "fill in this form, so we can set an agenda for a meeting to discuss how we're going to approach defining the requirements..."

One of them had Excel, Access and played with VBA, and in a couple of weekends had come up with a monstrosity that did just what they wanted. It lasted for years as a major part of their work toolbox until someone wrote a proper app for them in C#.

[lodovic]

But isn't that how it's supposed to work for these LOB type applications? Users prototype a solution and the developers then change it into a proper real world application. Alternative approaches are usually worse.

[jimbokun]

That whole process sounds like a reasonable division of responsibility.

The Software People get called in when it becomes difficult to maintain the ad hoc solution.

[mathgladiator]

And thats great because demand has be satisfied!

[TeMPOraL]

Yes. And the entire thing is done in half the time it would take for the development team's managers to get through whatever bullshit agile scrum epoch meetings to ultimately deny the request because it's not worth their time - or worse, approve the request, and get you waiting a year for The Project Done Right.