Reading Reflection 2
This paper discusses four different roles that computing research plays in addressing social problems. The first role it mentions is using computing as a diagnostic. Here, computing can help us quantitatively assess social problems and analyze their effects. Some of the example programs given involve using machine learning, algorithms, and complex decision-making using weighted factors. All of this involves heavy code and math.
I am currently taking the class CSE 331: Software Design and Implementation. We are learning about industry-standard code specifications that draw a hard line between programmers and clients. We are taught that these two people should almost always be seen as completely separate entities. A result of this is that the client, the user of the program, should never need to see any code to get the result they want. Sometimes this does make sense because code often takes a long time to decipher and understand, and so lots of time can be saved by just describing to the client what the code accomplishes.
However, I want to point out that this is how “black boxes” are created and why they are so common. The programs used for computing research that helps solve social problems are designed by computer scientists trained to keep the development process of their code hidden. This means that the non-programming researchers working on any given social issue will likely not be involved in as much algorithmic design as they should be. They might not feel this way because they still understand what the programs do, even though they are shielded from the assumptions made in programming and the weight given to any biases for decision making. Instead, it is the programmer who is solely responsible for making these choices.
I do agree with the paper on how computing as a diagnostic is very useful. Although, I do think it might be helpful if the computer science community considers modifying the standard procedures for writing code, so as to lessen the disadvantages of the systemic problem of “mysterious code”. In research environments, especially those aimed at helping the public good, it may also be beneficial to include a computer/data scientist on the team, whose sole role is to be skeptical about the data collected. This may force others on the team to reconsider any assumptions they make in collecting data and enable better experiments to be done.
Another thing the paper touched upon was using computing as a formalizer and a rebuttal. It argues that as a formalizer, computing can help us clarify our objectives and values because we need to explicitly define for the computer its inputs and how to process them based on their importance. The paper also argues that as a rebuttal, computing can help us to acknowledge the limitations of code so that we might focus on less technical solutions.
In my eyes, these two uses almost conflict with each other. This is best explained using an example. If we were to create a program for choosing certain high school students to be admitted to a college, we might spend countless hours discussing and debating precisely what we value in the applicants and the qualities we want them to have. We might define the traits and train our machine learning models to detect exactly the kinds of students we, theoretically, want.
Some people might draw the conclusion that no matter how precise you specify your code to be, there are intangible elements of an application that could never be properly evaluated by a computer. For example, in an applicant’s interview, the interviewer may pick up on their positive energy, similar to the kind of energy the interviewer knows a successful graduate of the school had. There are ways that you could try to translate that into a program (analyze the physiological traits of the applicant and compare that to successful alumni), but it is a question of whether making a computer program so precise is worth all the effort. Therefore, I wonder what might make an issue better solved by computing by formalizing as opposed to computing by rebuttal (ie not using computers).
