Information Technology and Ethics/Automation in Software Development

Gives Time to Employees Which Would Have Been Manual Labor:

A relatively increasing field within the Software Industry and even fields like software development is Automation. Now for many this concept must seem simple. It is the process of creating a script to automatically do something. This could be seen within IoT devices like Alexa when setting up your lights to turn on everyday at 8 AM or even something as simple as an alarm, to play a noise from your phone everyday at 8 AM for your class. Even in the workforce there are teams designated to automation script writing which is essentially writing scripts or programs which automatically does a specific task all on its own and oftentimes logs the status of that task on a dash. For example, let's look at the automation scripts which I have written during my internship while on the Cyber Security Automation Team at Chicago Mercantile Exchange (CME). In total I have written 4 automation scripts which save the company a total of about 135 minutes of manual labor a day. Looking at these results, automation is giving the company one of the most valuable aspects possible and that is time. This is 135 minutes of manual labor in which they have to pay a person to do and since I wrote these scripts, they no longer have to. That user may now devote their attention to other tasks which may hold more value to the company. On the daily the automation team is constantly talking to other teams about processes which they do that have the possibility of being automated. These scripts may be something as simple as checking if a server is active by pinging its host URL every 2 hours, or it could be running a list of over 20+ rule names on over 10,000 nodes across 5 different consoles. These are the times of scripts that I have written. Along with that time is saved from having to teach a manual process to another employee. For example, a process which took me a week to get comfortable with and learn how to do when I first came to CME, is something that I have now automated and no longer have to teach someone how to do step by step. On a side note, documentation writing is one thing that I did not expect to find as exhaustive within this field. Though I just mentioned that documentation writing would not be required on how to do a manual check, it is worth mentioning that we use that time to document how the automation process works, and some techniques or valuable lessons learned about automating that software in case someone has to write an automation on the same process in the future.

Eliminates Human Error:

Now when looking at automation time is extremely important but yet another thing that must be considered is the fact that this process eliminates the factor of human error. When doing manual tasks, especially those that get repetitive and require multiple steps which cause the user to wait on archive logs to load in, it is without a doubt possible that mistakes happen. If the manual check was to check the last archive logs on 30+ loggers to ensure everything has been properly archived and nothing has erred out, human mistakes will happen, trust me, I speak from experience. With the capability of using a script to check this on the other hand it is impossible for the script to improperly interpret a string being fed into it. If I tell a script to check if string == “Archived”: there is no possibility that it will ignore this logic when the variable string contains the value Archived. This is the power within automation, when properly written, there is no room for an error to occur. Though I make this process sound easy, oftentimes there are errors that still occur when an automation is first written as in the end of the day, we are still human and even when writing an automation script, human error occurs. If only we could automate automation writing.

Logs what is Valuable:

Going off of what I just talked about, it is important within automation scripts that the script writer must factor in proper error handling and logging. The script writer must know each and every error that may occur within the script, along with that they must note what is valuable, and what is something that is not worth time exploring. If you are automating a process and you know that X will break because of Y, then it has your automation tell log that. Someone else receiving a notification from your script who may not know this process like you do will now know to look directly at Y. It saves the time of having to troubleshoot because things were properly logged. Along with that, I found it was worthwhile to log each and every valuable piece of information your script is passing along the way. If you successfully pulled a value off an API call, log that value you are pulling so that each and every step along the way is properly documented in troubleshooting. Think of your script like a Lego where every valuable piece of information is another brick building your end goal. That being said, it is important to look at each case individually. It is hard to describe in words but do not over log, make sure what you are passing truly does hold value when troubleshooting. Over logging will drive you crazy and have you looking for a needle in a haystack.

Costs and Reflection of Automation

Now lets not forget the mere costs of automation, and essentially this goes back to time itself. In fact one of the scripts I wrote took nearly 4 months of troubleshooting and testing, involving requesting from software developers certain API calls, and communication across many different teams. That is time the company had to pay me on top of paying me to do the manual processes themselves at times. Along with that when working with automation I found it is important to make sure that your documentation on your scripts are well detailed so that if you consider an automation to “be done” and you move on to writing another, you know exactly what each brick of the Lego do in case you must come back to it if it hits a new roadblock. Though this seems very general, I cannot emphasize enough how important that documentation writing is. Have another person from a different team read over that documentation and see if they understand a general idea of what is going on. As one day in the future when this automation breaks after doing its job years after you moved on from the company, someone from the automation team should be able to pick it up and know each and every move it does.

Ethical Case within Automation:

When looking at the case of using software which automates the process of evaluating job applications, resumes, or college applications, we may see that there are both positives and negatives to this concept. When looking at this case using human evaluators (no automation). they will take a look at your resume or application and will read all of the information. After doing so they will decide if this information about you aligns with the information of a fitting candidate. They’ll listen to your responses in a job interview and gauge whether you answer “correctly.” Ideally, if you give responses that show you are qualified you will be selected. This process is much slower but it will give a more fair evaluation than looking at this process under automated software.

When automation comes to play here, we may see that universities or companies may automate this process under a concept similar to thresholds. Ideally they will filter a wide range of applications and collect only those that meet very specific criteria. If you have to have 5 years in the engineering field but only show 4 your application is essentially thrown out the window. So though we will get a larger amount of applications reviewed, they will be filtered under thresholds that may be unknown to the applicant, leaving an unfair expectation to be met. Though a pro to this process is that the automation will eliminate bias or discrimination. If the interviewer / application reviewer notices information for which they may have a bias towards, this can result in discrimination. For example, if you went to a school that they happened to dislike or if your gender was apparent from the application (if you say you had past experience in girl scouts, went to an all-boys school, etc.) and they made a decision based on this, there is bias here. If the reviewer has positive associations with topics discussed in an essay for a university or maybe positive association with a prior place you’ve worked for a job interview scenario and they hire / admit you based on this, this is also biased.

Though this is a very specific case, it is still one that dives deep into the ethics behind using automation. Automation as a field may be applied very largely in a variety of different fields or scenarios so though I talked very about my experiences with automation do not limit it to this scenario. I mean look at the software which takes into automating self-driving vehicles, that is another ethically challenging topic that may be looked upon as who would be at fault if a self-driving vehicle were to strike a civilian jaywalking. Or look at the examination of the Trolley Problem which we discussed in class, how would an autonomous vehicle decide there? This case would leave programmers to deal with ethical dilemmas that have been discussed for decades. These examples, and automation itself fits in accordance with Moore's Law, "[a]s technological revolutions increase their social impact, ethical problems increase". This discussion could lead to a whole other chapter in this book although for the sake of space and keeping this related to Automation, I thought it was merely worthwhile to bring up.

When looking at the ethics behind automation in software development it is nearly impossible to avoid talking about the consequences of automation taking away jobs. This idea has caused a real issue within the workforce known as automation anxiety. It is a concept that started off in the 60’s and was based on the idea that having software oriented machinery could be the rise of automation taking over manual labor jobs. Though this article and history itself largely spoke on machinery automation it is not too far-fetched to think that with the advancements of technology the possibilities of automation may be extended into many other fields. I mean even looking at the automation scripts which I have written, they took away the need for a person on the cyber defense engineering operations team to manually do these daily checks and that was coming off a beginner like myself. Although there are many positions that have far too many variables to consider automation it is not too farfetched to think that automation accompanied with AI may be a potential threat to the workforce in the future. Why would a worker want to pay someone if they know a software will run it at maximum efficiency with little to no errors? This is a real concern for unemployment that may be considered when considering the role of automation.