by Anonymous Coward writes:
on Thursday April 17, 2014 @12:10PM (#46779981)
Macros are the main problem keeping back a switch to LibreOffice or OO.o. Also, paid commercial support (so that Joe Smith can call up an "engineer" at 3 AM on a holiday Sunday with an urgent issue and get a hotfix issued by 7 AM).
The macro problem is bigger than most people (i.e., those outside Corporate or Public Sector America) realize. On many large enterprise systems, the computer is so locked down that to develop almost any kind of automation, or work productivity software, is nigh impossible. So, assuming you know some basic stuff about software development and you're tired of clicking and dragging on the same cells in Excel 500 billion times, you have two choices: either suck it up and click until you get a repetitive stress injury, or break out the VBA.
Most enterprises (at least, those I've worked at) don't restrict the use of VBA macros, so they've become a sort of "programming environment of last resort" for worker bees in companies that are either too cheap, or too stupid to deploy actual development software like Visual Studio or Eclipse. And even those employees who decide to go off-roading and fly in the face of corporate policy to install "un-approved" software (heretics; how dare they!) will run into major roadblocks related to not having administrative privileges on their system.
VBA code does not port seamlessly without major changes to the LibreOffice/OpenOffice environment; it basically has to be rewritten, depending on the complexity. Long story short, there are entire enterprise systems implemented in VBA (typically based on MS Access or MS Excel), often with copious use of Win32 API functions, which include networking, databases, custom file formats, custom GUIs (UserForms), and so on and so forth. These systems can save hundreds of hours of manual labor and improve the quality of life for people who work for a living and are just trying to get shit done, despite cloistered "departments" impinging from all sides, trying to impede their progress to the fullest extent possible due to NIH and general paranoia about software that they themselves didn't select (but when one of the IT guys who pulls the strings decides they really like some cool new program that helps THEM in THEIR job, of course it gets immediately installed on everyone's systems without so much as a security sniff-test).
Hiring an intern to work on one of these for a summer or two, or hoping and praying that you recruit someone who's willing to work for near-minimum-wage with a background in programming, is often the only thing separating corporate drones from RSI-inducing repetitive work. And don't go to the IT department and ask them to develop or buy a system, oh no; they never have the budget, and even if they did, they wouldn't be able to sit down with your boss's boss's boss for a Project Scope Agreement meeting until July 2017.
VBA, from a pragmatic perspective, is a loophole that skunkworks people have been gleefully exploiting for close to 20 years now. If you propose to do away with it by removing Office from peoples' computers and putting OO.o or LO in its place, you'll incite a riot. If you do it anyway, your business will grind to a halt as productivity and efficiency drop by a factor of 100.
If you're an IT director with a hand in a decision like this, I urge you to survey ALL your employees -- not just the managers who have no clue what their employees do -- to see what impact a transition from MS Office to LO/OO.o would have. I'm not saying a move is impossible, but you need to do it in cooperation and coordination with your employees. Yes, even the inconvenient ones who like to download zipballs with those "Open Sauce" EXEs that you don't trust. They're the good guys; they're helping your company; and they're just trying to get their work done as efficiently as possible.
Also, paid commercial support (so that Joe Smith can call up an "engineer" at 3 AM on a holiday Sunday with an urgent issue and get a hotfix issued by 7 AM).
Close, but you've mixed up hours with months, or even years. The only bug I ever reported to Microsoft (an error in the daylight saving handling of their C runtime library) got fixed 7 YEARS later.
Macros. (Score:3, Interesting)
Macros are the main problem keeping back a switch to LibreOffice or OO.o. Also, paid commercial support (so that Joe Smith can call up an "engineer" at 3 AM on a holiday Sunday with an urgent issue and get a hotfix issued by 7 AM).
The macro problem is bigger than most people (i.e., those outside Corporate or Public Sector America) realize. On many large enterprise systems, the computer is so locked down that to develop almost any kind of automation, or work productivity software, is nigh impossible. So, assuming you know some basic stuff about software development and you're tired of clicking and dragging on the same cells in Excel 500 billion times, you have two choices: either suck it up and click until you get a repetitive stress injury, or break out the VBA.
Most enterprises (at least, those I've worked at) don't restrict the use of VBA macros, so they've become a sort of "programming environment of last resort" for worker bees in companies that are either too cheap, or too stupid to deploy actual development software like Visual Studio or Eclipse. And even those employees who decide to go off-roading and fly in the face of corporate policy to install "un-approved" software (heretics; how dare they!) will run into major roadblocks related to not having administrative privileges on their system.
VBA code does not port seamlessly without major changes to the LibreOffice/OpenOffice environment; it basically has to be rewritten, depending on the complexity. Long story short, there are entire enterprise systems implemented in VBA (typically based on MS Access or MS Excel), often with copious use of Win32 API functions, which include networking, databases, custom file formats, custom GUIs (UserForms), and so on and so forth. These systems can save hundreds of hours of manual labor and improve the quality of life for people who work for a living and are just trying to get shit done, despite cloistered "departments" impinging from all sides, trying to impede their progress to the fullest extent possible due to NIH and general paranoia about software that they themselves didn't select (but when one of the IT guys who pulls the strings decides they really like some cool new program that helps THEM in THEIR job, of course it gets immediately installed on everyone's systems without so much as a security sniff-test).
Hiring an intern to work on one of these for a summer or two, or hoping and praying that you recruit someone who's willing to work for near-minimum-wage with a background in programming, is often the only thing separating corporate drones from RSI-inducing repetitive work. And don't go to the IT department and ask them to develop or buy a system, oh no; they never have the budget, and even if they did, they wouldn't be able to sit down with your boss's boss's boss for a Project Scope Agreement meeting until July 2017.
VBA, from a pragmatic perspective, is a loophole that skunkworks people have been gleefully exploiting for close to 20 years now. If you propose to do away with it by removing Office from peoples' computers and putting OO.o or LO in its place, you'll incite a riot. If you do it anyway, your business will grind to a halt as productivity and efficiency drop by a factor of 100.
If you're an IT director with a hand in a decision like this, I urge you to survey ALL your employees -- not just the managers who have no clue what their employees do -- to see what impact a transition from MS Office to LO/OO.o would have. I'm not saying a move is impossible, but you need to do it in cooperation and coordination with your employees. Yes, even the inconvenient ones who like to download zipballs with those "Open Sauce" EXEs that you don't trust. They're the good guys; they're helping your company; and they're just trying to get their work done as efficiently as possible.
Re: (Score:2)
Close, but you've mixed up hours with months, or even years. The only bug I ever reported to Microsoft (an error in the daylight saving handling of their C runtime library) got fixed 7 YEARS later.