6 ms·

> It was really quite depraved but it worked > but alas the overworked, underskilled, and somewhat frightened IT person couldn't stomach the risk this seems l

> It was really quite depraved but it worked > but alas the overworked, underskilled, and somewhat frightened IT person couldn't stomach the risk this seems like a reasonable call to me.

BeetleB 6y ago
Not at all. He could have written his own program and just used it, and IT would never have gotten involved. Because it was using a 3rd party tool, IT got lazy. My company, BTW, not only explicitly allows AHK, they actually encourage it. I mean, if you're going to give people compilers to write arbitrary code, this is not worse.
- WaxProlix 6y ago
  It seems weird to expect someone with no programming training (an IT guy) to either build or sign off on something they have no understanding of. In large/high stakes settings, being risk averse and knowing the limits of your understanding are very good traits. Imho, this IT guy did his job, more or less. What was the testing plan for this AHK script? What edge cases were considered? Unit tests, integ tests.... was there a preprod environment for it? A trial run? Can you safely roll back if / when bad data shows up? What's the retry strategy for network or up/downstream fault tolerance? Is there alarm or monitor coverage for bad scenarios? I'm not saying a bunch of people typing are error prone, if that's your take on my post. I just think that there's a VERY different set of risks (and therefore mitigations) between a distributed manual process and a large scale automated one. The IT guy might have on some level recognized this and judged the possible loss to be way more than the "guaranteed loss" of the not-broken current process. If I were an IT guy with low level skills, I'd be proud of myself for making that hard call.
  - jimmaswell 6y ago
    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.
  - BeetleB 6y ago
    > It seems weird to expect someone with no programming training (an IT guy) to either build or sign off on something they have no understanding of. Once again, if I wrote my own Python script they would not be involved, and my Python script is as error prone as using AHK. Think of AHK as similar to a compiler + linker. By rejecting AHK because someone can write a program that could screw things up, you might as well just prevent people from writing scripts and compiling programs. > I'm not saying a bunch of people typing are error prone, if that's your take on my post. I just think that there's a VERY different set of risks (and therefore mitigations) between a distributed manual process and a large scale automated one. You've essentially argued that IT should oppose any automation that is not thoroughly tested. And how will they determine how well it is tested? Do they have those skills? Where I work, IT is more concerned about security (viruses, theft, etc), licensing, and things that can break the machine. They don't prevent people from using APIs to mass edit databases as long as you do it to data you own or have permission from the owner. They don't own the data, so you're free to screw it up if you're careless. Ensuring my program is bug free and well tested is the job of my team/org/data owners, not IT. You're merely pointing out that this IT person has been given more power than his skills warrant.
    - WaxProlix 6y ago
      Okay but if you have an organization whose lead of IT isn't capable of verifying some automation - be it AHK or Python or VisualBasic or F# or haskell or whatever - then it's fine for them to say 'no'. You can go over their head, and that's also okay. Or ask them to bring in someone who's an expert in the technology you're using. > You've essentially argued that IT should oppose any automation that is not thoroughly tested. And how will they determine how well it is tested? Do they have those skills? In large scale, business critical applications? Yes. All everything should be thoroughly tested and/or canaried, with several levels of validation before production releases. > You're merely pointing out that this IT person has been given more power than his skills warrant. I think I'm pointing out that his job is to be a safeguard against rogue wanna-be programmers whose ability to destroy things far outstrips their ability to test for things (or even think about edge cases). If that's true, they've done a fantastic job.
  - i1856511 6y ago
    Exactly. A lot of programmers, or programming enthusiasts, thumb their nose at IT staff who naturally push back on stuff like this. In their mind, to play devil's advocate, they're seeing IT as unnecessarily burdensome, and getting in the way of automation. The IT staff are probably naturally welcoming to the general idea of automation. However, to elevate something up from an off the cuff script that's described as "depraved" to the level of an actual business tool that can be relied upon, is a HUGE time and money sink. Validation is a very complex problem as you have described. This is the difference between consumer and enterprise hardware. If business management isn't setting this as a priority for IT, and if IT is already overwhelmed with the "known" quantities of work, then it just isn't practical to officially adopt. I see it like this: It takes 1 "effort point" for a data entry staffer to manually enter the information tediously. It takes 10 effort points for the same staffer to write the AHK script to automate it. (Good for the staffer, assuming there's no flaws, and their reward is a longer lunch break.) To truly validate an automation as a business tool would take something on the scale of 150 to 200 effort points and involve lots of conversation - assuming there even is a framework for new tool validation established that can be used. IT knew this and made the right call. If company management wants to adopt a new tool without research and validation, that can be reckless.
  - keeganpoppen 6y ago
    why even have programmers if they have to convince someone that doesn't understand what they're doing that it's been implemented correctly? the justification of an ignorant person not understanding it (assuming, i guess(?), that they are also incapable of learning it, apparently?) and thus not allowing a massively more efficient improvement to be put in place as somehow a job well done seems crazy to me. (at least in theory managers are supposed to provide something to the table). well, i guess to all the other programmers who, like me, leave any and all places like this. i acknowledge that not everyone is wired the same way, but it just seems blatantly obvious that the left hand wants "innovation" and the right hand... does stuff like this.
    - TeMPOraL 6y ago
      Everyone wants innovation, but no one wants responsibility. So anything can go as long as someone else signs off on it.
  - TeMPOraL 6y ago
    > It seems weird to expect someone with no programming training (an IT guy) to either build or sign off on something they have no understanding of. In large/high stakes settings, being risk averse and knowing the limits of your understanding are very good traits. Which raises the question, why does such a person even have the authority to make calls on what software can or can not be used within the company? You shouldn't have the right to make these kind of decisions without basic understanding of how software works (beyond "I click stuff and things happen, magic!"). > What was the testing plan for this AHK script? What edge cases were considered? Unit tests, integ tests.... was there a preprod environment for it? A trial run? Can you safely roll back if / when bad data shows up? What's the retry strategy for network or up/downstream fault tolerance? Is there alarm or monitor coverage for bad scenarios? Without understanding of how software is built, those are questions the IT guy can't possibly ask thoughtfully. They become a mere checkbox ticking exercise. And most of them don't apply anyway. > If I were an IT guy with low level skills, I'd be proud of myself for making that hard call. It's not a hard call. It's the easy call. The ass-covering, responsibility-mitigating, work-minimizing, consequence-free default deny call.
  - silasdavis 6y ago
    Some good points. Some more context: this made a manual process semi manual. You still had to enter the data and the target programs still flew around (on screen) on the background. I think the risk profile was similar. > Unit tests, integ tests.... was there a preprod environment for it? A trial run? Can you safely roll back if / when bad data shows up? Nothing of the sort :) But... Let the adequate be the enemy of the less awful?
- WaxProlix 6y ago
  I don't think AHK or python or whatever is the issue here, it's automating the consumption of a ton of data without consulting the consumers or vendors of that data, or enacting correctness guarantees. It seems like you're hung up on AHK vs not-AHk and that's not something I care about. I've seen and been involved in a lot of naive automation of human processes just to see all of the edge cases destroy a business for weeks or more on end.
- silasdavis 6y ago
  So actually he didn't want to be responsible for deploying more widely. I kept on using it. I was probably not meant to.
silasdavis 6y ago
Perhaps. It certainly wouldn't have been me that had to live with it. It might have been hard to stop using it. To give some context this was a utility company. The gas pipes were consumer and commercial supply lines. You need to know where they are buried so people don't blow themselves up digging them up. It was safety critical. >> It was really quite depraved but it worked The baseline context for this, though, is a very error prone process. It was common for me to register a pipe in the technical specification (size depth etc) system and map that (by rekeying the handwritten ID) and accidentally pick a different location in the system for indicating connection of service to main pipes. You could have a service pipe (to someone's house) registered to a main in a completely different area. My script eliminated these types of errors. The other thing to note is it didn't change the underlying process. You could, and I did, check the underlying form fills (something I wouldn't bother doing when it took 6 times as long). I'm not trying to denigrate the individual here, he might have been doing his best given his knowledge and level of autonomy (he might also have been chickenshit) but as an organisation they let some value fall on the floor from an employee because they had no mechanism to capture and integrate it.
- Reelin 6y ago
  If it really reduced the required time six fold, the obvious safety-productivity win-win would be to independently (ie different workers) enter everything twice. You would enjoy a three fold improvement in time requirements, should nearly eliminate all basic data entry errors, and significantly improve the employee experience. Or you could just decide to pass on all that, that's always an option I suppose.

> It was really quite depraved but it worked > but alas the overworked, underskilled, and somewhat frightened IT person couldn't stomach the risk this seems like a reasonable call to me.

BeetleB 6y ago

Not at all. He could have written his own program and just used it, and IT would never have gotten involved. Because it was using a 3rd party tool, IT got lazy. My company, BTW, not only explicitly allows AHK, they actually encourage it. I mean, if you're going to give people compilers to write arbitrary code, this is not worse.

WaxProlix 6y ago
It seems weird to expect someone with no programming training (an IT guy) to either build or sign off on something they have no understanding of. In large/high stakes settings, being risk averse and knowing the limits of your understanding are very good traits. Imho, this IT guy did his job, more or less. What was the testing plan for this AHK script? What edge cases were considered? Unit tests, integ tests.... was there a preprod environment for it? A trial run? Can you safely roll back if / when bad data shows up? What's the retry strategy for network or up/downstream fault tolerance? Is there alarm or monitor coverage for bad scenarios? I'm not saying a bunch of people typing are error prone, if that's your take on my post. I just think that there's a VERY different set of risks (and therefore mitigations) between a distributed manual process and a large scale automated one. The IT guy might have on some level recognized this and judged the possible loss to be way more than the "guaranteed loss" of the not-broken current process. If I were an IT guy with low level skills, I'd be proud of myself for making that hard call.
- jimmaswell 6y ago
  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.
- BeetleB 6y ago
  > It seems weird to expect someone with no programming training (an IT guy) to either build or sign off on something they have no understanding of. Once again, if I wrote my own Python script they would not be involved, and my Python script is as error prone as using AHK. Think of AHK as similar to a compiler + linker. By rejecting AHK because someone can write a program that could screw things up, you might as well just prevent people from writing scripts and compiling programs. > I'm not saying a bunch of people typing are error prone, if that's your take on my post. I just think that there's a VERY different set of risks (and therefore mitigations) between a distributed manual process and a large scale automated one. You've essentially argued that IT should oppose any automation that is not thoroughly tested. And how will they determine how well it is tested? Do they have those skills? Where I work, IT is more concerned about security (viruses, theft, etc), licensing, and things that can break the machine. They don't prevent people from using APIs to mass edit databases as long as you do it to data you own or have permission from the owner. They don't own the data, so you're free to screw it up if you're careless. Ensuring my program is bug free and well tested is the job of my team/org/data owners, not IT. You're merely pointing out that this IT person has been given more power than his skills warrant.
  - WaxProlix 6y ago
    Okay but if you have an organization whose lead of IT isn't capable of verifying some automation - be it AHK or Python or VisualBasic or F# or haskell or whatever - then it's fine for them to say 'no'. You can go over their head, and that's also okay. Or ask them to bring in someone who's an expert in the technology you're using. > You've essentially argued that IT should oppose any automation that is not thoroughly tested. And how will they determine how well it is tested? Do they have those skills? In large scale, business critical applications? Yes. All everything should be thoroughly tested and/or canaried, with several levels of validation before production releases. > You're merely pointing out that this IT person has been given more power than his skills warrant. I think I'm pointing out that his job is to be a safeguard against rogue wanna-be programmers whose ability to destroy things far outstrips their ability to test for things (or even think about edge cases). If that's true, they've done a fantastic job.
- i1856511 6y ago
  Exactly. A lot of programmers, or programming enthusiasts, thumb their nose at IT staff who naturally push back on stuff like this. In their mind, to play devil's advocate, they're seeing IT as unnecessarily burdensome, and getting in the way of automation. The IT staff are probably naturally welcoming to the general idea of automation. However, to elevate something up from an off the cuff script that's described as "depraved" to the level of an actual business tool that can be relied upon, is a HUGE time and money sink. Validation is a very complex problem as you have described. This is the difference between consumer and enterprise hardware. If business management isn't setting this as a priority for IT, and if IT is already overwhelmed with the "known" quantities of work, then it just isn't practical to officially adopt. I see it like this: It takes 1 "effort point" for a data entry staffer to manually enter the information tediously. It takes 10 effort points for the same staffer to write the AHK script to automate it. (Good for the staffer, assuming there's no flaws, and their reward is a longer lunch break.) To truly validate an automation as a business tool would take something on the scale of 150 to 200 effort points and involve lots of conversation - assuming there even is a framework for new tool validation established that can be used. IT knew this and made the right call. If company management wants to adopt a new tool without research and validation, that can be reckless.
- keeganpoppen 6y ago
  why even have programmers if they have to convince someone that doesn't understand what they're doing that it's been implemented correctly? the justification of an ignorant person not understanding it (assuming, i guess(?), that they are also incapable of learning it, apparently?) and thus not allowing a massively more efficient improvement to be put in place as somehow a job well done seems crazy to me. (at least in theory managers are supposed to provide something to the table). well, i guess to all the other programmers who, like me, leave any and all places like this. i acknowledge that not everyone is wired the same way, but it just seems blatantly obvious that the left hand wants "innovation" and the right hand... does stuff like this.
  - TeMPOraL 6y ago
    Everyone wants innovation, but no one wants responsibility. So anything can go as long as someone else signs off on it.
- TeMPOraL 6y ago
  > It seems weird to expect someone with no programming training (an IT guy) to either build or sign off on something they have no understanding of. In large/high stakes settings, being risk averse and knowing the limits of your understanding are very good traits. Which raises the question, why does such a person even have the authority to make calls on what software can or can not be used within the company? You shouldn't have the right to make these kind of decisions without basic understanding of how software works (beyond "I click stuff and things happen, magic!"). > What was the testing plan for this AHK script? What edge cases were considered? Unit tests, integ tests.... was there a preprod environment for it? A trial run? Can you safely roll back if / when bad data shows up? What's the retry strategy for network or up/downstream fault tolerance? Is there alarm or monitor coverage for bad scenarios? Without understanding of how software is built, those are questions the IT guy can't possibly ask thoughtfully. They become a mere checkbox ticking exercise. And most of them don't apply anyway. > If I were an IT guy with low level skills, I'd be proud of myself for making that hard call. It's not a hard call. It's the easy call. The ass-covering, responsibility-mitigating, work-minimizing, consequence-free default deny call.
- silasdavis 6y ago
  Some good points. Some more context: this made a manual process semi manual. You still had to enter the data and the target programs still flew around (on screen) on the background. I think the risk profile was similar. > Unit tests, integ tests.... was there a preprod environment for it? A trial run? Can you safely roll back if / when bad data shows up? Nothing of the sort :) But... Let the adequate be the enemy of the less awful?
WaxProlix 6y ago
I don't think AHK or python or whatever is the issue here, it's automating the consumption of a ton of data without consulting the consumers or vendors of that data, or enacting correctness guarantees. It seems like you're hung up on AHK vs not-AHk and that's not something I care about. I've seen and been involved in a lot of naive automation of human processes just to see all of the edge cases destroy a business for weeks or more on end.
silasdavis 6y ago
So actually he didn't want to be responsible for deploying more widely. I kept on using it. I was probably not meant to.

silasdavis 6y ago

Perhaps. It certainly wouldn't have been me that had to live with it. It might have been hard to stop using it. To give some context this was a utility company. The gas pipes were consumer and commercial supply lines. You need to know where they are buried so people don't blow themselves up digging them up. It was safety critical. >> It was really quite depraved but it worked The baseline context for this, though, is a very error prone process. It was common for me to register a pipe in the technical specification (size depth etc) system and map that (by rekeying the handwritten ID) and accidentally pick a different location in the system for indicating connection of service to main pipes. You could have a service pipe (to someone's house) registered to a main in a completely different area. My script eliminated these types of errors. The other thing to note is it didn't change the underlying process. You could, and I did, check the underlying form fills (something I wouldn't bother doing when it took 6 times as long). I'm not trying to denigrate the individual here, he might have been doing his best given his knowledge and level of autonomy (he might also have been chickenshit) but as an organisation they let some value fall on the floor from an employee because they had no mechanism to capture and integrate it.

Reelin 6y ago
If it really reduced the required time six fold, the obvious safety-productivity win-win would be to independently (ie different workers) enter everything twice. You would enjoy a three fold improvement in time requirements, should nearly eliminate all basic data entry errors, and significantly improve the employee experience. Or you could just decide to pass on all that, that's always an option I suppose.