Critical code studies is an approach that applies critical hermeneutics to the interpretation of computer code, program architecture, and documentation within a socio-historical context. CCS holds that lines of code are not value-neutral and can be analyzed using the theoretical approaches applied to other semiotic systems in addition to particular interpretive methods developed particularly for the discussions of programs. (CITEREFMarino2006)
How does one go about this approach, from a practical point of view? What are guiding questions? What is the method?
Practical Steps
- Create context: Who wrote the code and why? How do socio-political and historical contexts frame the software?
- Classify software at hand: is it closed or open source, what is its intended goal, etc.
- Create a mental model of the code base
- “scan the overall architecture while reading comments if available; commentary texts are priceless”: Get an overview and do a rough reading. Gather basic technological information on programming language and hardware. How is the code structured and organised?
- “[R]ead the code and its documentation to determine what the code does; discuss the code with its authors; reading code with one or more others to discover a variety of perspectives”
- Use IDEs “for tracing variable states, arguments, and functions while providing a nonlinear means for exploring code”. Regex can help.
- Ask questions and do a close reading
- Have your own research question at hand and see how the code base connects to it.
- See below for Some guiding questions
- Run the code
- Use the software or play the game.
- Use external monitoring software to look out for internal changes, e.g. dynamic analysis.
Some guiding questions
who created it, when, where, and why. This begins the historical, archaeological, and sociological research that will ground the reading. If the authors of the code are still alive, I may try to interview them. Otherwise, their documentation is extremely valuable in this process. [@CriticalCodeSMarino2020, p.24]
How does the implementation of the code (inside) reflect or contrast the functioning of the software (outside) or vice versa? How typical is this code within its more general class of software or algorithms? Where do its core ideas lie? What is anomalous about this code (for so much code is reused from similar code found elsewhere)? What methods or other sections of the code seem to capture the central idea of the software, its key contributions? (See the final chapter of this book for more of these initial questions.) But the code is not enough in itself. It is crucial to explore context. Who wrote the code? When and why? In what language was the code written? What programming paradigm was used? Was it written for a particular platform (hardware or software)? How did the code change over time? What material or social constraints impacted the creation of this code? How does this code respond to the context in which it was created? How was the code received by others? [@CriticalCodeSMarino2020, p.28]
On Tools
However, reading code does not mean staring at monochromatic character strings. Douglass (2011) early in the evolution of CCS suggested using a syntax highlighter or even an integrated development environment (IDE) to see the code the way developers do. IDEs also include advanced features for tracing variable states, arguments, and functions while providing a nonlinear means for exploring code. There are several freely available IDEs, such as Eclipse or Netbeans, which was used to develop the Transborder Immigrant Tool (chapter 3). Alternatively, code readers could use web applications such as Jupyter Notebooks, R Markdown, Apache Zeppelin, or Spark Notebook, which enable the creation of documents with running code in them so that code readers can more readily see the effects of code. Reading code is not like examining other texts because software contains assemblages of processes with changing states (Vee 2017). Nonetheless, this emphasis on reading more complex software does not exclude the reading of code-like artifacts through CCS. [@CriticalCodeSMarino2020, p.28]