I had a similar experience, combining Excel (and VBA) with Perl and some other toolsets. I tend not to get too specific on here, but this allowed me to survive a major downsizing and extreme lack of budget while greatly improving accuracy and schedules, and to ride out a series of drastic changes to inputs that were "thrown over the wall" to my department. If I were to mention the dollar amounts being managed through those workbooks, people would shudder.
Excel has its cruft, and depending upon what you're doing you have to learn by experience some of its odder and dimmer (danker?) corners. But, that aside, IJFW. And quickly, and without choking.
That said, if you don't know what you're doing... Well, I had to "correct" a lot of people who assumed that because the machine showed them a number, it was right.
Excel will not enforce correct design, nor thinking.
Which reminds me of some crap dBASE programming I had to clean up, some years prior. And any number of other things.
It's not Excel. It's the people using it, and the people who assign them to use it without accounting for those people's limitations (and their own, apparently).
I have found mistakes in (other people's!) Excel spreadsheets that amounted to (real) 6 figure problems...
Then again a replacement system would probably cost about the same.
I was in a position where I did not have resources for anything else. (Yes, ironic, given the dollar amounts I was handling. But then, welcome to "big business"...)
And, with the changing shit raining down from on high, as well as the need to adapt processes for my own sake and survival, it ended up being for the best, anyway.
Within a limited value of "best". In retrospect, better would have been, ultimately, to be working somewhere else. (Though for a time, the relative autonomy and one very decent direct manager were rather nice.)
Some of the improvement I provided was correcting the outputs of a longstanding legacy system that routinely borked a "random" subset of its data. People had ostensibly looked and been unable to correct this in the original code, and at the time management felt it had no budget to work on this further, at the mainframe level.
So, I guess.... to some extent, it's not the system, it's what you do with it! Old, big dollar legacy project fucked up, and we ended up fixing it on the PC. LOL's aplenty.
Excel has its cruft, and depending upon what you're doing you have to learn by experience some of its odder and dimmer (danker?) corners. But, that aside, IJFW. And quickly, and without choking.
That said, if you don't know what you're doing... Well, I had to "correct" a lot of people who assumed that because the machine showed them a number, it was right.
Excel will not enforce correct design, nor thinking.
Which reminds me of some crap dBASE programming I had to clean up, some years prior. And any number of other things.
It's not Excel. It's the people using it, and the people who assign them to use it without accounting for those people's limitations (and their own, apparently).