4 ms·

As much as I can imagine MS would love to kill VBA it would be a major loss of business if they did. Oil and Gas lives in the stuff and would probably even sue

by leeter 8y ago

As much as I can imagine MS would love to kill VBA it would be a major loss of business if they did. Oil and Gas lives in the stuff and would probably even sue MS if VBA died. That said could it be getting a much needed fixup... probably. I suspect the same is true of COM plugins.

nwsm 8y ago
I'm in Oil and Gas app dev, we are .net with no VBA. I guess I'm lucky.
- sten 8y ago
  Dev in finance here, VBA gets used more than I care to think about.
  - artmageddon 8y ago
    My last job in finance(still am in finance fwiw) used much more VBA to price out billion-dollar swaps and swaptions than I was comfortable admitting to...
- leeter 8y ago
  I dealt with it peripherally in my last job. Apparently the only reason Office has a 64bit version at all is Oil and Gas was causing Excel to run out of ram and demanded it. We were developing a COM addin, and we had clients complain that we broke some of their VBA they were using (turned out it was another VBA addin they were using that wasn't doing proper error handling). But it was definitely common for us to see clients that were deep into VBA.
- privacypoller 8y ago
  Don't count yourself so sure - A lot of shadow IT gets done by that excel expert in finance or the engineer who took a programming elective. If anyone ever gave them a database login password, odds are they're pulling into excel or access and writing VBA!
LarryDarrell 8y ago
I rewrote a 3000 line VBA function into C# earlier this year for a Oil/Gas company. It was surprisingly easy. Sometimes tedious, but easy. It runs faster, it's easier to maintain and now they can slap whatever front-end they want on it. Is it money, fear or gatekeeping that keeps these VBA programs untouchable?
- ender341341 8y ago
  Most of them aren't maintained by technical people. Someone wrote some excel file years ago and every month it's copy pasted and the new data put in place of the old and it usually works until it doesn't.
- Maybestring 8y ago
  It's simply that the people doing the development only get to use VBA. Not that having a chemical engineer teach themself C# over their lunch break is going to turn out great software... Having worked at a big company as a mechanical engineer and produced a few crappy VBA apps, I did it because it would take significantly more time and effort to get approval for an IT project, than to learn VBA and do it myself.
- HeyLaughingBoy 8y ago
  Probably all three. I used to be in the Medical Devices field. A couple years ago, I was told to add a feature to a massive VBA app hosted in Excel that we (S/W development) inherited from another department. It was hands down the worst code I have ever seen. Everything was a global variable. I flat out told my boss that it barely worked, didn't come close to meeting the weakest of our development standards, and since it was used to disposition product (determine whether or not it was acceptable to be used on Patients) it was an FDA audit nightmare waiting to happen. I added the features, but made some pretty unpleasant commit comments since I didn't want to have my fingerprints all over it. In all fairness, it was originally developed by a scientist with no SW dev training (I knew him well) for his own use, and just grew over the years as he was told to add more features to it. I have no idea how a company with that level of process strictness ever allowed this fiasco to happen. [rant over] I estimated the rewrite at 6-12 months. It was really not a very complex program and since we already had the Validation tests written and documented, we at least knew what tests its replacement would need to pass. The problem was all the stuff that we knew it was doing that wasn't in any of the tests. That would have been the majority of time spent to replace it. Since I left, I heard ownership of it was transferred to Corporate IT and they were making it into a web app to run on their intranet. Heaven help those guys.
agumonkey 8y ago
Killing VBA would be a business error, deprecating it with proper transition (language analysis, translation) would be a business hygiene.

by leeter 8y ago

nwsm 8y ago

I'm in Oil and Gas app dev, we are .net with no VBA. I guess I'm lucky.

sten 8y ago
Dev in finance here, VBA gets used more than I care to think about.
- artmageddon 8y ago
  My last job in finance(still am in finance fwiw) used much more VBA to price out billion-dollar swaps and swaptions than I was comfortable admitting to...
leeter 8y ago
I dealt with it peripherally in my last job. Apparently the only reason Office has a 64bit version at all is Oil and Gas was causing Excel to run out of ram and demanded it. We were developing a COM addin, and we had clients complain that we broke some of their VBA they were using (turned out it was another VBA addin they were using that wasn't doing proper error handling). But it was definitely common for us to see clients that were deep into VBA.
privacypoller 8y ago
Don't count yourself so sure - A lot of shadow IT gets done by that excel expert in finance or the engineer who took a programming elective. If anyone ever gave them a database login password, odds are they're pulling into excel or access and writing VBA!

LarryDarrell 8y ago

I rewrote a 3000 line VBA function into C# earlier this year for a Oil/Gas company. It was surprisingly easy. Sometimes tedious, but easy. It runs faster, it's easier to maintain and now they can slap whatever front-end they want on it. Is it money, fear or gatekeeping that keeps these VBA programs untouchable?

ender341341 8y ago
Most of them aren't maintained by technical people. Someone wrote some excel file years ago and every month it's copy pasted and the new data put in place of the old and it usually works until it doesn't.
Maybestring 8y ago
It's simply that the people doing the development only get to use VBA. Not that having a chemical engineer teach themself C# over their lunch break is going to turn out great software... Having worked at a big company as a mechanical engineer and produced a few crappy VBA apps, I did it because it would take significantly more time and effort to get approval for an IT project, than to learn VBA and do it myself.
HeyLaughingBoy 8y ago
Probably all three. I used to be in the Medical Devices field. A couple years ago, I was told to add a feature to a massive VBA app hosted in Excel that we (S/W development) inherited from another department. It was hands down the worst code I have ever seen. Everything was a global variable. I flat out told my boss that it barely worked, didn't come close to meeting the weakest of our development standards, and since it was used to disposition product (determine whether or not it was acceptable to be used on Patients) it was an FDA audit nightmare waiting to happen. I added the features, but made some pretty unpleasant commit comments since I didn't want to have my fingerprints all over it. In all fairness, it was originally developed by a scientist with no SW dev training (I knew him well) for his own use, and just grew over the years as he was told to add more features to it. I have no idea how a company with that level of process strictness ever allowed this fiasco to happen. [rant over] I estimated the rewrite at 6-12 months. It was really not a very complex program and since we already had the Validation tests written and documented, we at least knew what tests its replacement would need to pass. The problem was all the stuff that we knew it was doing that wasn't in any of the tests. That would have been the majority of time spent to replace it. Since I left, I heard ownership of it was transferred to Corporate IT and they were making it into a web app to run on their intranet. Heaven help those guys.

agumonkey 8y ago

Killing VBA would be a business error, deprecating it with proper transition (language analysis, translation) would be a business hygiene.