In Week 2 of lecture, you learned about using the techniques of benchmarking (i.e., measuring run time in our test framework) and counting the number of writes to “boxes” of memory, to determine performance characteristics of different algorithms using a Vector. Next week, we will expand and formalize our accounting of the number of steps in an algorithm using a technique called Big-O analysis, which will inform our study of algorithms throughout the rest of the course. However, we want to approach the topic of efficiency and optimization with a certain amount of cautious skepticism in terms of its ethical implications. This assignment is designed to prepare you to learn about Big-O by pausing to consider these implications.
Question 9:
In a short paragraph, describe a real or plausible scenario not previously presented in lecture in which using techniques like benchmarking or counting “write” steps to improve the performance of an algorithm might benefit Earth’s environment. Include your thoughts on how a software engineer working on this piece of code might identify such potential benefits and take them into consideration when designing the code.
As ethical and socially-conscious computer programmers, we also know that many considerations other than the speed and runtime are important in choosing the appropriate algorithm for a particular use. Dr. Gillian Smith, an associate professor at the Worcester Polytechnic Institute, identifies an interesting fallacy that computer scientists often fall into when applying algorithmic analysis techniques like benchmarking and Big-O analysis:
If it’s more efficient, it’s better. The quality of a program, independent of how people interact with it, should be evaluated only with respect to how well it minimizes cost.
The next two questions relate to this concept.
Question 10:
The following case study illustrates the importance of supplementing efficiency and performance analyses with human-centric evaluation.
In 2006 the state of Indiana awarded IBM a contract for more than $1 billion to modernize Indiana’s welfare case management system and manage and process the State’s applications for food stamps, Medicaid and other welfare benefits for its residents. The program sought to increase efficiency according to two measures: time until customer case files were resolved, and reduce fraud. After only 19 months into the relationship, while still in the transition period, it became clear to Indiana that the relationship was not going as planned. In particular here are some “lowlights” of the system’s failures to provide important and necessary services for those in need:
- “Applicants waited 20 or 30 minutes on hold, only to be denied benefits for ‘failure to cooperate in establishing eligibility’ if they were unable to receive a callback after having burned through their limited cellphone minutes.”
- “Applicants faxed millions of pages of photocopied driver’s licenses, Social Security cards, and other supporting documents to a processing center in Marion, Indiana; so many of the documents disappeared that advocates started calling it “the black hole in Marion” […] Any application missing just one of tens to hundreds of pieces of necessary information or paperwork were automatically denied."
- The automated system often arbitrarily closed cases, to keep the time until customer case files were “resolved” low. Customers of course did not consider their issue truly resolved, but in the metrics it would count as resolved.
- “By February 2008, the number of households receiving food stamps in Delaware County, which includes Muncie, Indiana, dropped more than 7 percent, though requests for food assistance had climbed 4 percent in Indiana overall.” (Quotations from this article written by Virginia Eubanks.)
In light of these failures, the State of Indiana cancelled its contract with IBM and sued the company for breach of contract, stating that the company had failed to deliver a system that was supposed to help people get the services they needed. In court, IBM argued that they were not responsible for issues related to phone wait times, appeals, wrongful denials, lost documents, etc. as the contract only stated that a successful system would succeed by reducing costs from fraud, and reducing time until each case was resolved, both of which they achieved (they argued). IBM’s system did reduce costs, but did so by denying people the benefits they needed. In light of this, we would like you to consider the following questions:
Question: If criteria like minimizing wrongful denials were not included in the contract, should engineers have included them in their optimization algorithm anyway? Why or why not?
If you’re interested in reading more about this case study, we highly recommend reading the linked article above. The author, Virginia Eubanks, also wrote a great book titled Automating Inequality that can make for interesting further exploration!
Question 11:
Review the Twitter image cropping algorithm we talked about at the end of Lecture 6. The algorithm that was used was a measure of the amount of information in an area of an image that uses Claude Shannon’s concept of “information” as entropy, or in this case, the amount of contrast between adjacent pixels of the image. This algorithm is a quick and easy one to implement, as far as image analysis algorithms go. But it clearly had a terrible outcome when applied to images of people. Imagine that you took CS106B several years ago, and after completing CS106B, you were hired at Twitter as an engineer working on the image cropping system. How might you have approached setting the goals of this system? Is there a way you could design the procedures for code testing and release in your group to avoid the severe negative impacts on users of the system that are outlined in the case study?