Life in Code and Software/Introduction
Back to the book
This book explores the relationship between living and code and software. It does so because these technologies are increasingly part of our urban environment, and indeed stretching even to very remote areas of the world. The book introduces and explores the way in which code and software become the conditions of possibility for human living, crucially becoming a computational ecology which we inhabit. As such we need to take account of this new computational world and think about how we live today in a highly mediated code-based world.
Today we live in a software society. All around us software is running to make our lives more comfortable, safer, faster, and convenient. From the entertainment systems that we use to listen to music and watch television, to the engine systems that allow us to experience unprecedented fuel efficiency and even electric cars, software is doing the heavy lifting that makes the old industrial and consumer experience better.
Software studies is a field that uses approaches drawn from philosophy, politics, history, anthropology, sociology, media studies, computer science, and the humanities more generally, to try to understand the way in which software increasingly penetrates our everyday life. As a relatively new discipline it has a two-fold challenge of having to reorder and construct methods and theories that are appropriate to studying software. Additionally the field is still undertaking the difficult task of uncovering helpful exemplars and examples that can assist in the teaching of software studies itself.
Crucially it is important to recognize that software requires a platform upon which to run. Platforms can be either hardware or software based but they provide the conditions and environment which makes it possible for the software to function correctly. One of the difficulties with studying software is that is requires a complete assemblage of technologies in order to work at all, what we might call its infrastructure. This might be the specific model of computer or processor that is needed to run the software, or it might be a particular operating system, or network. This necessarily complicates the study of software and needs to be born in mind when studying software. Nonetheless, it can nonetheless be analytically useful to draw distinctions between different levels of analysis when thinking about software in order to try to understand what it can and cannot do, and more importantly how we might think about understanding it. These are (1) Software Layer, (2) Software Platform, and (3) Hardware Platform.
The main reason for drawing these distinctions is it enables us to pay attention to the salient focus of the analysis we wish to undertake in this book, without losing sight of the importance of the supporting hardware and software. This form of layering of different technologies on top of each other is very common in computer technology and you will see different forms of this structure throughout the book.
The most important aspect of this layering model is to abstract the hardware from the software. This is crucial in software to enable software to, in theory, run anywhere, without having to know too much about the specifics of the underlying technologies. Of course, this is an ideal scenario and even today few technologies can make this claim confidently, although technologies like HTML, Java, and so forth, were explicitly designed for just this reason.
It is important to note that these technologies are digital technologies, but merely appreciating that they are made up of so-called digital code (0’s and 1’s) doesn’t get us very far. Instead we have to take account of the fact that the internal structures that enable things to become softwarized is complex and very structured. The main distinction that is used today is that between applications (or apps) and files (or data). It is common for them to be combined together in a so-called wrapper that hides this from the user, for example in many mobile operating systems, but the basic distinction still remains beneath the screen.
Media and software
When media is incorporated into software it is transformed into files. For example, when a song is taken from a physical medium, such as CD or DVD, it is encoded into a digital file, for example MP3 or AAC. We are very familiar with this concept when using PCs and laptops.
However there is also a move to transforming media content into ‘apps’ or media rich software experiences. Taking the example of music again, rather than create a series of MP3 files after encoding (ripping) the CD, instead some musicians are experimenting with turning the album into a self-standing app for playing and interacting with the music itself. This is important to note because these two ways of interacting with media are very different and draw on different repertoires within the computer interface.
As old media forms, like TV, film and newsprint, are digitized, there is experimentation by designers and programmers on the best form to present media content to the user. Clearly the media forms are all being softwarized in the process – as the way in which the content is used is mediated through a software interface – however, there are a number of paradigms that shape the way in which media is interacted with including:
Applications and files Apps (wrapping the media) Streams (including real-time streams) Clouds (where media is held in a digital asset database)
When transformed into software: firstly, a new media object is subject to algorithmic manipulation. In short media becomes programmable. Secondly, streaming media are any media built around a continuous data-flow, and this will likely be the paradigmatic form of media for the future. This means that media will increasingly be subject to regular and repeating computation.
Why Study Software?
It is clear then that media is changing and that if we are not careful we will make the mistake of allowing past mediums limit our understanding of the new software-based media. We certainly need to be aware of the pressure software is exerting on these old ways of understanding media and in moving to a new paradigm of knowledge, ensure that we take the old media theory that still is appropriate whilst leaving behind that which is too closely wedded to the older broadcast technologies.
Additionally, software itself is changing rapidly due to limitations now being experience in the capacity of hardware to support old software paradigms. For example, many of our computing systems, and certainly those that we have used in everyday life, have been built around single processor systems that we expected to get faster and faster based on the notion of Moore’s Law, that is, that computer speed roughly doubles every eighteen months. Physical limitations are now being hit in the design of computer chips, and therefore rather than increase the speed (measured in Hz, MHz, or GHz), instead chip manufacturers are increasingly the number of ‘cores’ or processors that we have in our machines. Software is therefore the new focus of the massive advances in speed and capability in hardware design. However, most programming is still written in a form that assumes fairly simple computer structures and hardware – like a single core to the processor. We are therefore living in a time of a dual transformation of both, (i) a general move to a softwarized media world, but also (ii) that software itself is about to enter a change in paradigm to take account of rapid change in the hardware environment too which means more stream-based computation.
This includes the shift from relatively static desktop computers to mobile computers, indeed in 2006 according to the ITU, there were 2.7 billion mobile devices vs 850 million desktop computers, with YouTube alone streaming video media of 200 terrabyte per day.
The changing location for microprocessors, increasingly embedded in all sorts of everyday devices, from washing machines to coffee-makers, highlights the extent to which we rely on software. All of these chips need software to run, without which they would essentially by plastic, metal and glass bricks.
Iteracy
Iteration itself, is a term used in computing to refer to the repetition of a command, code fragment, process, function, etc. Understanding iteration is a crucial skill for developing programming skills as it is a means of re-using existing processes (looping structures). But also, iteration itself, combined with constant improvements, is a key way of developing software/code (very much associated with agile programming, for instance).
An example of iteration in Zajal code is (Zajal is a programming language):
5.times do text "Hello" end
This instructs the computer to perform the task text "Hello", or print Hello to the screen, five times in a repetitive loop, or iteration.
Here though I want to broaden the meaning of iteracy beyond mere iteration/looping structures in programming code. What skills, then, might be associated with this notion of iteracy? Computational Thinking: being able to devise and understand the way in which computational systems work to be able to read and write the code associated with them. For example abstraction, pipelining, hashing, sorting, etc. (see Wing 2011).
- Algorithms: understanding the specifically algorithmic nature of computational work, e.g. recessions, iteration, discretisation, etc.
- Data and Models: understanding the significance and importance of data, information and knowledge and their relationships to models in computational thinking.
- Reading and Writing Code: practices in reading/writing code require new skills to enable the reader/programmer to make sense of and develop code in terms of modularity, data, encapsulation, naming, commentary, loops, recursion, etc.
- Learning programming languages: understanding one or more concrete programming languages to enable the student to develop a comparative dimension to hone skills of iteracy, e.g. procedural, functional, object-oriented, etc.
- Code Aesthetics: developing skills related to appreciating the aesthetic dimension of code, here I am thinking of 'beautiful code' and 'elegance' as key concepts (see Oram and Wilson 2007).
I also talk about a notion of 'digital bildung' but that is meant to be a broader term which would include iteracy as a constituent part. Digital Bildung and computationality (see Berry 2011) are larger frameworks of knowledge and practices around computational literacy, broadly conceived. However, iteracy is the name for the specific skills used for understanding code and algorithmic culture – as indeed literacy (understanding texts) and numeracy (understanding numbers) do in a similar context. That is, iteracy is specifically the practice or being able to read and write code, rather than the more extensive notion of digital Bildung (see Berry 2011: 20-26). In short, Bildung is still a key idea in the digital university, not as a subject trained in a vocational fashion to perform instrumental labour, nor as a subject skilled in a national literary culture, but rather as subject that can unify the information that society is now producing at increasing rates, and which understands new methods and practices of critical reading (code, data visualisation, patterns, narrative) and is subject to new methods of pedagogy to facilitate it (Berry 2011: 168). So digital Bildung would include the practices of iteracy and would build on them to facilitate a broader humanistic or critical education. Here, then, iteracy is defined broadly as communicative competence in reading, writing and executing computer code. But also, iteration itself, combined with constant improvements, is a key way of developing software/code (very much associated with agile programming, for instance). An example of iteration in C++ code is:
int loop = 1; while (loop <= 10) { cout << "Iteration #" << loop << endl; loop++; }
Why is "literacy' insufficient as a term?
Of course, it isn't that 'literacy' is necessarily insufficient, but perhaps clunky when we start talking about 'code literacy', 'information literacy', 'data literacy', 'media literacy', etc. etc. Consider it a quick hack to create more meaning with less information by lopping off the 'l'.
The idea really follows from the idea that we don't talk about number literacy we talk about numeracy, we don't talk about word literacy, we talk about literacy, and it is also playful, having a strong association with the notion of iteration. Iteration, or looping structures more generally, are hugely important to understanding how and why computers function at all, it is also very important in order to read code to be able to see these structuring principles for code. See below for an extended 'content' for the concept. One thing we have to bear in mind is that we have not overly narrowed the definition of iteracy to ‘formal programming’. In this context I have found it very useful to explain to students that they are 'programming' a computer when they set an alarm on their iPhone or negotiate a menuing system in photoshop. This highlights that it is ‘blackboxes’ all the way down in computer systems. Iteracy, therefore, includes the abstract principles of computational thinking, as well as the specifics of learning programming in terms of source=>executable. I think that this is important in order to highlight the disadvantages that face individuals that do not have these basic skills around using computational devices. Increasingly 'iteracy' will be crucial for operating in this computational culture - especially considering the ontologies or models that are delegated into the computational devices that surround us take for granted certain computational principles of operation
"Messy" programming vs Literate programming
When teaching iteracy we need to attend to the fact that certain ways of ‘writing’ code create functioning software. You cannot write random symbols into a computer and expect it to have an intended effect. Here, my intention is not to 'prevent' simple programming steps via examples – nor to prevent play or experimentation with different ways of writing code. But students will not get very far in using some of the more powerful potentialities of computation if iteration, etc., is not introduced in a timely manner, and preferably as soon as possible. That is why so many programming languages offer loops, iteration, recursion, procedures and so forth as a means of creating easily iterable blocks of code. I would also say, remarking on the choice of programming language for learning iteracy, that it is crucial that it is an accessible language but not too much of a 'toy language', that is, that you can 'build' real stuff with it. I, personally, think that that was one of the huge advantages of Basic, way back in the mists of time. Certainly programming languages have moved on now and so we need to find a new base language that can teach simple, moderate and then more complex ideas that are transferable to other languages with ease. Zajal/Ruby seems to me a good starting point, but this is certainly something that will be found in experiments in teaching code more generally.
I would like to say in addition to this that having grasped the basic principles of iteracy is crucial for reading code and for undertaking critical code studies at all. But also for using computational media. I think of the difficulty of using something like 'Motion' or 'After Effects' without understanding the basic principles of using and creating loops of visual material, or modern music composition using 'Logic Pro' or 'Pro Tools' without understanding samples, loops of samples, and the aggregation and layering of effects. These are deeply computational ways of working with media, and those who understand iteracy, I would argue, have an advantage in creating and using these systems and platforms, because of the cognitive maps iteracy provides for circumnavigating complex menuing, object-oriented visual structures, creating looping aggregates, and so forth.
This, of course, allows us to draw the distinction of source code (code as text) and compiled code (software as executable) and the fact that written differently may actually have the same effect (i.e. compile to the same thing). Certainly with the smartness of many compilers removing the need to worry too much about 'efficiency' and resource allocation this is the case. So writing code has some flexibility in how things are implemented (see later chapters that discuss this in detail in relation to object functions and immediate functions).
So, often when it comes to code, the emphasis is on documented code, readable code, literate code that can be maintained and scaled and remains comprehensible. Indeed many of the great leaps forward in computing, such as object oriented programming, are less to do with efficiency (in code), and more to do with comprehensibility of large systems for design and implementation (reading and writing of code systems and aggregates).
By contrast 'messy' programming is not literate programming and in some senses need to be balanced as a step in the learning process for iteracy. This is not to say it isn’t useful as a stepping stone to building software systmes, indeed many of the methodologies in computer science are aimed at helping to reduce messy code and therefore the bugs associated with it ('spagetti code').
The point isn't that iteracy is used to define what is and isn't code, rather it is to highlight the way in which code has certain affordances towards repetition and iteration. That these structures are built into the background of the syntax of the programming language and the practices associated with programming. Additionally computer science itself is highly geared towards elegance and efficiency in writing algorithms and code and it is important for us to take account of that, even to critique or highlight counter-examples and anomalies in code.