Methods for Studying Algorithms

At last, this is the third part of the mini-series on “studying algorithms”. The previous try to explain why doing so is important and the difficulties you might encounter while doing so.

So, now let’s get to the actual “Hows”. The following sections are high-level overviews over some methods that are out there. They should help you with deciding which to dive deeper into when studying algorithms.

Studying the people

To understand an algorithm, it often helps to know where it came from and for whom it was built. For this studying the people and businesses who created it and the people who use it can be useful. For this, there’s a variety of methods commonly used in social sciences. Usually they’re divided into qualitative (e.g. interviews) and quantitative (e.g. questionnaires) ones.

Qualitative methods also include ethnographic field studies – an example would be observing coding teams at work. This can allow to understand the culture and assumptions that the algorithm came from. “How to Study Algorithms” [ref:HtS] mentions that it can be hard to gain access to the teams for this, though. In the same article John Danaher points out, that you can also widen the focus and study “the full set of legal, economic, institutional, technological, bureaucratic, political (etc) forces” that might influence the algorithm’s development.

On the quantitative side of things, you can give people questionnaires. The authors of “Auditing Algorithms” [ref:AAg] point out a problem of questionnaires: There is a difference between what people do and what they perceived, remember and report. To avoid this problem, you can ask them to allow you to collect data automatically (e.g. via a browser plugin or a tracking script).

Reading the Source

This method can be used if the sources are available – either because they have been open-sourced or because you’re one of the trusted auditors [ref:Opc] mentioned above. Reading them and their documentation can help with understanding what the algorithm is doing. You can gather additional data by looking at the changes the code underwent over-time or by comparing implementations in different languages and frameworks.

There’s two problems you’ll probably run into:

Firstly, the size of code-bases.

Secondly, that discrimination won’t be something hard-coded in a single code-block. It can be spread out over the entire thing; you will probably only find it if you read between the lines. Almost certainly you won’t find a block like the following anywhere:

if ($race = NOT_CAUCASIAN) then {
  illegal_discrimination()
};

Implement it Yourself

The idea is that by implementing the system yourself, you will understand the required steps and parts better by doing so. Rob Kitchin named this method “Reflexively producing code” in his paper “Thinking Critically About and Researching Algorithms” [ref:Crt]

The inspiration for this approach are auto-ethnographic methods. Examples for these are keeping a journal/diary and observing one-self. As with any of them, your personal biases, assumptions and views will strongly influence the results.

Scraping

You download the entire thing, e.g. a set of home-pages, and explore them, e.g. by clustering them. The article “Auditing Algorithms” [ref:AAg] lists several limitations for this though:

Some pages constantly change as they’re personalized (e.g. Google results differ between persons and searches)

It might be necessary to log in manually or fill a captchas

There most likely will be legal restrictions, e.g. in the Terms of Service, that forbid you from doing this.

In the case of smaller servers it might even significantly tax the performance. This in turn will probably cost the provider money and worsen the experience of other users.

Lastly, another problem it shares with a few other methods, is that there’s no independent variable. These are elements you directly manipulate, to observe the resulting changes. An example would be something you enter into a search-box and the search-results you get. In comparison, scraping usually tries to just load everything. This might make it hard to impossible to find out what is the cause of things. It also makes it more prone to any personal biases and hidden assumptions.

Black Box Audit

You systematically, but manually input different things into the algorithm (e.g. queries in Google’s search box). This input is your independent variable. Then you look at the differences in the output. From them, you can try to figure out what happens inside the algorithm.

However, usually you can’t collect too much data by hand. This in turn makes rather hard to completely understand what really causes the results. If you do the inputting automatically and generate a lot of results, evaluating them can become a challenge.

Sock Puppet Audit

This method, described in “Auditing Algorithms” [ref:AAg], for instance is suited for studying social networks.

The basic idea is as follows: You start by creating fake accounts (the “sock puppets”). Then you flesh them out as far as necessary to make the algorithm register them as real humans. The point is to have some of these accounts vary in some way, e.g. their name and picture communicate different genders; these are your independent variables.

As opposed to scraping, this method can deal with login walls.

Even more importantly, having independent variables allows reasoning about cause and effect. Socket puppets still suffer from the same legal restrictions as scraping though. Also, there’s the question of how much data do puppets need to be “real enough”.

As a distinct downside, this method is usually used without the prior consent of the people running the algorithms. The fake data from the sock puppets can negatively influence the algorithm. This is especially the case, when there’s not many other users. Think of this before using the method and make sure to always get consent afterwards!

Also, as the method is often used to prove guilt, you should take extra care with your choices: what you try verify/falsify as well as which independent variables to use.

Collaborative Audit

To deal with the issues of legality and realness of sock puppet audits, you can also hire a lot of human testers, as “Auditing Algorithms” [ref:AAg] sugggests. For this you can for instance use crowd-sourcing platforms like Mechanical Turk (US-only atm). The independent variable then depends on who you chose to recruit.

However, this method has some limitations too:

It’s more expensive as you have to pay the testers. Also, at least for Mechanical Turk, the tasks you give people need to be very short and well defined, e.g. “perform task X, save the resulting HTML and send it to us”.

In some cases a community of volunteers can get together to do collaborative audits together, making the process a lot more affordable.