4 ms·

You absolutely do not need all that red tape to use a script written for a well-known program. The IT guy just didn't care to spend the teensiest mental energy

You absolutely do not need all that red tape to use a script written for a well-known program. The IT guy just didn't care to spend the teensiest mental energy to save people an enormous amount of work. "No" is the easiest, safest call possible, not a hard call at all. People like him should be shamed.

WaxProlix 6y ago
Spoken like someone who's never caused a prod outage at a real company, I guess. I'd say that - outside of some startup or small company that has few (or no?) users - the cautious approach is right. The IT guy knew that he was a podunk pissant warden of a very, very small portion of very, very large organization (an org of a few hundred people is basically nothing compared to the vastness of many oil companies) and that the value that his org provided was compromised by this automated approach, without knowing how to mitigate that compromise. He made the right call, assuming he was just there as a bulwark against exactly this.
- airstrike 6y ago
  There's no "prod outage" here. It was a data entry script.
  - WaxProlix 6y ago
    What happens with that data, though? Is this a non production data entry job?
    - airstrike 6y ago
      Same that would happen with the manual typing process. The workflow either includes a process for auditing data quality or it doesn't, regardless of how it was entered in.
      - WaxProlix 6y ago
        Okay, is that a manual process or not? Why not start with automating the testing and not the entry?
        TeMPOraL 6y ago
        Because testing is probably not done at all. And even if it was, it isn't the bottleneck in this story.
- jsharf 6y ago
  It's a data entry script. If it fails they just do their job the old way until the guy fixes it. It's typing text into forms. Just make everyone do things the "old way" once a week so they still know how to do it if the script ever fails.
  - WaxProlix 6y ago
    Okay, but after a week (or two or whatever), how do you rectify the issue you found? It's easy to say get those people back and have them start entering again. What about the customers whose information was inaccurate, the resources that were misallocated, etc? Do you think data entry is done for fun? At AWS we use massive metrics and piles of data to decide what's right; why would an oil company be different, just because their metrics are collated by hand from smaller oil wells into larger spreadsheets or whatever? "By Hand" doesn't mean "totally without value", that's completely wild. Does your super low opinion of data entry people cloud your vision of their value? There's not been a response to my question of how you reconcile things after this script messes up for the first time; how does that happen? What's the DR plan? if you have real business and real clients working on this data, tell me what the plan is; it shouldn't be that hard.
i1856511 6y ago
"Shamed", come on. You don't ask the guy in charge of maintenance to validate new tools. That person's job revolves around stability, and they will always make the safest possible call. If a new tool is needed, a steering committee of some kind should be used, and IT will be one part of that.
- BeetleB 6y ago
  Where I work, IT in general has little say about what tool I use on my PC. They do periodic scans to check that I don't have any known unsafe tools, or tools that are known not to be OK without a formal license. But otherwise, as long as I'm not violating a license and not circumventing my virus scanner, I can use whatever tool I want. Work would come to a crawl if IT had to validate every single tool used in our company. The notion that this is within IT's scope is flawed. It's the equivalent of asking a government agency to vet every single product that is produced by any company for consumer safety in the whole of the United States, and then rejecting most of them because of the lack of resources to thoroughly vet them.
  - WaxProlix 6y ago
    Would they get in trouble when someone used an automation tool that submitted hundreds of thousands of empty or even worse completely incorrect records, with no reconciliation plan? If so, then they're completely right to stop some novice programmer from bringing their scripts to bear. There's no reason to take that risk if they have the funding for the current human solution. Bring it up to the superiors and pitch it, talk to some devs. I've seen groups lose hundreds of millions of dollars when one of these excel vbscript python enthusiast AHK things go off the rails. It's a mess, and - again - risk aversion is the most reasonable stance from a business standpoint. He's not a hacker founder, he's a business IT manager. Edit to say, it sounds like you work at a company with <500 engineers, maybe even <500 employees total. That's fine! It's good even, but it's not an experience that's easily exported to the realm of Actual Business, at least not exactly. As a consultant, I've had billion dollar companies that need the fast fix (python script with a csv datastore to keep some account info or whatever) and I've worked for companies where this sort of approach would get you insta-canned. They're both right enough, but assuming one size fits all is absolutely crazy. It sounds like the mega oil corp above was the latter, at least to me.

WaxProlix 6y ago

Spoken like someone who's never caused a prod outage at a real company, I guess. I'd say that - outside of some startup or small company that has few (or no?) users - the cautious approach is right. The IT guy knew that he was a podunk pissant warden of a very, very small portion of very, very large organization (an org of a few hundred people is basically nothing compared to the vastness of many oil companies) and that the value that his org provided was compromised by this automated approach, without knowing how to mitigate that compromise. He made the right call, assuming he was just there as a bulwark against exactly this.

airstrike 6y ago
There's no "prod outage" here. It was a data entry script.
- WaxProlix 6y ago
  What happens with that data, though? Is this a non production data entry job?
  - airstrike 6y ago
    Same that would happen with the manual typing process. The workflow either includes a process for auditing data quality or it doesn't, regardless of how it was entered in.
    - WaxProlix 6y ago
      Okay, is that a manual process or not? Why not start with automating the testing and not the entry?
      - TeMPOraL 6y ago
        Because testing is probably not done at all. And even if it was, it isn't the bottleneck in this story.
jsharf 6y ago
It's a data entry script. If it fails they just do their job the old way until the guy fixes it. It's typing text into forms. Just make everyone do things the "old way" once a week so they still know how to do it if the script ever fails.
- WaxProlix 6y ago
  Okay, but after a week (or two or whatever), how do you rectify the issue you found? It's easy to say get those people back and have them start entering again. What about the customers whose information was inaccurate, the resources that were misallocated, etc? Do you think data entry is done for fun? At AWS we use massive metrics and piles of data to decide what's right; why would an oil company be different, just because their metrics are collated by hand from smaller oil wells into larger spreadsheets or whatever? "By Hand" doesn't mean "totally without value", that's completely wild. Does your super low opinion of data entry people cloud your vision of their value? There's not been a response to my question of how you reconcile things after this script messes up for the first time; how does that happen? What's the DR plan? if you have real business and real clients working on this data, tell me what the plan is; it shouldn't be that hard.

i1856511 6y ago

"Shamed", come on. You don't ask the guy in charge of maintenance to validate new tools. That person's job revolves around stability, and they will always make the safest possible call. If a new tool is needed, a steering committee of some kind should be used, and IT will be one part of that.

BeetleB 6y ago
Where I work, IT in general has little say about what tool I use on my PC. They do periodic scans to check that I don't have any known unsafe tools, or tools that are known not to be OK without a formal license. But otherwise, as long as I'm not violating a license and not circumventing my virus scanner, I can use whatever tool I want. Work would come to a crawl if IT had to validate every single tool used in our company. The notion that this is within IT's scope is flawed. It's the equivalent of asking a government agency to vet every single product that is produced by any company for consumer safety in the whole of the United States, and then rejecting most of them because of the lack of resources to thoroughly vet them.
- WaxProlix 6y ago
  Would they get in trouble when someone used an automation tool that submitted hundreds of thousands of empty or even worse completely incorrect records, with no reconciliation plan? If so, then they're completely right to stop some novice programmer from bringing their scripts to bear. There's no reason to take that risk if they have the funding for the current human solution. Bring it up to the superiors and pitch it, talk to some devs. I've seen groups lose hundreds of millions of dollars when one of these excel vbscript python enthusiast AHK things go off the rails. It's a mess, and - again - risk aversion is the most reasonable stance from a business standpoint. He's not a hacker founder, he's a business IT manager. Edit to say, it sounds like you work at a company with <500 engineers, maybe even <500 employees total. That's fine! It's good even, but it's not an experience that's easily exported to the realm of Actual Business, at least not exactly. As a consultant, I've had billion dollar companies that need the fast fix (python script with a csv datastore to keep some account info or whatever) and I've worked for companies where this sort of approach would get you insta-canned. They're both right enough, but assuming one size fits all is absolutely crazy. It sounds like the mega oil corp above was the latter, at least to me.