4 ms·

"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

"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.
  - BeetleB 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? As I said in my comments above, it's a question of who owns the data. In general, other than things like financial information and HR records, IT does not own the data in our company. They provide lots of services (version control, Jira boards, etc). They often are responsible for backing them up at a specified interval (daily, etc). And they are responsible for configuring them to be secure (which may involve shutting off APIs). But they don't own whether someone can write a script to automate clicking on fields, etc. They don't own the data and outside of the agreed backup are not responsible for it. They absolutely would not get in trouble if someone automated something that destroyed that data. The policy is "We provide the service, but you are responsible for what goes into it and how." They do not need to see that we've vetted people's scripts for bugs, etc. They expect us to be responsible. If the data is lost, we will be in trouble, not them. If IT was responsible for every database, Jira board, etc in the company beyond their regular backup, little work would be done. It's a huge company, and we cannot have one org be a bottleneck. At times they do need to put some restrictions, but even in those cases, the department is free to get their own hardware and run their own database/JIRA board/whatever. There are a few security requirements to hook it up to the network, but IT will not get in our way if we set up our own Jira board/DB. They'll just tell us that we are responsible for backing things up nor will they provide support if we break things. This is why my company has lots of pseudo-IT teams across departments. The company wide IT is responsible for the big things. The smaller pseudo-IT teams exist to be more flexible and not be constrained. They don't exist in defiance of IT - IT actually endorses it. > I've seen groups lose hundreds of millions of dollars when one of these excel vbscript python enthusiast AHK things go off the rails. But why is IT responsible for it? Perhaps in your company this is in their purview, but not in ours. And I'd argue that it shouldn't be. IT cannot go into every org and police what VBA scripts people use, and if they did they'd likely do more harm than good. While you may have seen losses of hundreds of millions of dollars, I'm pretty sure the gains from Excel VBA scripts is much, much more. > Edit to say, it sounds like you work at a company with <500 engineers, maybe even <500 employees total. Nope. Well over 50K employees, with over 60% of them being engineers. Likely the top company in the field we're in. No one has answered my question that I brought up several times: If I can write my own program to do it, should they ban compilers as well? I'm sorry but whatever damage a VB script can do can also be done by C#. Should we ban Visual Studio?

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.
- BeetleB 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? As I said in my comments above, it's a question of who owns the data. In general, other than things like financial information and HR records, IT does not own the data in our company. They provide lots of services (version control, Jira boards, etc). They often are responsible for backing them up at a specified interval (daily, etc). And they are responsible for configuring them to be secure (which may involve shutting off APIs). But they don't own whether someone can write a script to automate clicking on fields, etc. They don't own the data and outside of the agreed backup are not responsible for it. They absolutely would not get in trouble if someone automated something that destroyed that data. The policy is "We provide the service, but you are responsible for what goes into it and how." They do not need to see that we've vetted people's scripts for bugs, etc. They expect us to be responsible. If the data is lost, we will be in trouble, not them. If IT was responsible for every database, Jira board, etc in the company beyond their regular backup, little work would be done. It's a huge company, and we cannot have one org be a bottleneck. At times they do need to put some restrictions, but even in those cases, the department is free to get their own hardware and run their own database/JIRA board/whatever. There are a few security requirements to hook it up to the network, but IT will not get in our way if we set up our own Jira board/DB. They'll just tell us that we are responsible for backing things up nor will they provide support if we break things. This is why my company has lots of pseudo-IT teams across departments. The company wide IT is responsible for the big things. The smaller pseudo-IT teams exist to be more flexible and not be constrained. They don't exist in defiance of IT - IT actually endorses it. > I've seen groups lose hundreds of millions of dollars when one of these excel vbscript python enthusiast AHK things go off the rails. But why is IT responsible for it? Perhaps in your company this is in their purview, but not in ours. And I'd argue that it shouldn't be. IT cannot go into every org and police what VBA scripts people use, and if they did they'd likely do more harm than good. While you may have seen losses of hundreds of millions of dollars, I'm pretty sure the gains from Excel VBA scripts is much, much more. > Edit to say, it sounds like you work at a company with <500 engineers, maybe even <500 employees total. Nope. Well over 50K employees, with over 60% of them being engineers. Likely the top company in the field we're in. No one has answered my question that I brought up several times: If I can write my own program to do it, should they ban compilers as well? I'm sorry but whatever damage a VB script can do can also be done by C#. Should we ban Visual Studio?