5 ms·
They don't discuss the flip side of this, which is the hell of an organisation groaning under the weight of thousands of unsupportable Excel VBA scripts and Acc
by bencollier49 7y ago
They don't discuss the flip side of this, which is the hell of an organisation groaning under the weight of thousands of unsupportable Excel VBA scripts and Access databases (oh, and now UIPath jobs!) whose authors have left the business, and which could fail at any moment when an upstream dependency just goes away...
- buzzkillington 7y agoI had one job which could at best be described as 'Excel VBA DevOps' it was in a bank. Someone had cost the company millions when yahoo finance changed the end point for currency conversion and no one noticed it was using stale data for a few months.
- WalterBright 7y agoI have to rewrite my accounting code every year to deal with Paypal CSV files because they change the way they work. A constant nuisance.
- pintxo 7y agoI‘d argue using yahoo finance in the first place as data source is the issue here.
- buzzkillington 7y agoExcel is the issue because it hid that dependency in the right most column (ABB) on the 4th sheet of the excel file.
- bencollier49 7y agoExcel didn't do that, the person who wrote the spreadsheet did that!
- kimjongtrill 7y agothis is staggeringly hilarious. wow.
- crispyambulance 7y agoI 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.
- datashow 7y ago> 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.
- crispyambulance 7y agoThey 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.
- rb808 7y agoIts not just Excel. I have legacy bash/perl/python scripts sprinkled liberally around my world and it never gets better.