Some (very quick) thoughts on Critical Engineering

I’ve been following an interesting thread over on the Empyre forums between Cesar Baio, Simon Biggs, Davin Heckman and Gabriel Menotti. It’s basically a conversation on the ambiguous nature of accessible artworks created by technology and in particular, computing programming languages. I was struck by a comment made by Julian Oliver (who recently showed some fantastic work at transmediale, part of the Labor Berlin show).

Simon Biggs: “Much contemporary computer based art work has a cargo-cult like quality due to such illiteracy. This can be interesting but usually in spite of itself.”

Julian Oliver: “Indeed, also one of the fruits of Bricolage. However with a language like Engineering having such influence over the lives and minds of people – how we eat, travel, communicate – I really think you need to speak the language to truly act critically within its scope.

This is what we sought to underscore in the manifesto:

http://criticalengineering.org

I’ve talked to several artists that have expressed disempowerment in this age of database automation, google maps, wireless networking, the Cloud etc – technologies that shape how they live and even their practice yet they find no entry point to dissassembling and thus critically engaging them. It’s not enough to talk about how we are influenced by all this engineering – technology that becomes social, political and cultural infrastructure – this leaves us in little better position. It must be engaged it directly to understand the mechanics of influence. This is the difference between a topic (technology) and as a material (engineering).

Most that receive this email will have little or no idea how it arrived to their inbox, unable to accurately describe it to another, not even close. At the same time most would be able to describe how a postcard arrived at their friends mailbox. Just 15 years..

Ignorance as to how these engineered infrastructures actually function, what they do and what is done with them behind their own presentation, is actively being abused both inside and out of democracies.”

Clearly there’s much truth here. Understanding how technologies work (especially the proprietary ones) and how they construct and mediate technological experience adds heft to ones artistic ability to undermine and tinker with those structures if need be. At present this is now badged with the ‘new materialism’ trend blossoming around media studies; an interest in the material connections and contingent points of technological construction. This is a materialism I can get on board with – finding entry points and understanding the connections. Kudos to Julian for making the stakes clear.

My response to this however is to reinforce some ontological questioning on behalf of those technologies that we wish to critically engineer. Humans are incredibly good at being sanguine about their technological reliance, as Julian suggests. Hardly any of us are aware of the almost infinitesimal amount of functions, strings, algorithms and bits which construct our mediated existence, proprietary or open source – but we’d need not beat ourselves up over the lack of freedom that comes with it.

If Heidegger ever taught us anything about technology (the menacing Bremen lectures notwithstanding) it’s that daily existence itself constantly misses most of the elements that construct our limited experience. Both proprietary programming and open source programming conceal their functions from us, because they are coded using the paradigmatic logic of encapsulation (which is part of a bigger relationship between ontology as philosophy and ontology as programming). The difference, the crucial difference, is that open source is built with an additional precondition of open modification.

It’s worth reminding that human experience does not execute strings, nor compile a source language into a target language, the things themselves do this. We never, nor will have absolute knowledge of computing functions.

This is why I’m always concerned (yet generally supportive) with software studies. One gets the general sense (and Wendy Chun has said something similar I believe) that one has cracked some meaningful challenge if one discovers the ‘source’ of proprietary software. That the finding of the source is only goal for meaningful political activity (for example the recent trend of printing the fork bomb script on T-Shirts – as if simply knowing the code conceptually is enough knowledge).

I’d suggest that being ‘critically engaged’ with our reliance on media need not involve seeking the source or accurately describing every last detail of how a code works. Being critically engaged must begin with surrendering conceptual knowledge of the thing itself. You are not the thing. This need not be a backstep, because it can be said that political activity itself is built from such a lack of knowledge. You think private companies know absolutely every last detail about the platforms and software they create? Of course they don’t. Computing, source code or otherwise, does not favour your knowledge and expectation – it’s history has been shown to thoroughly surprise any capacity to know and to critique. Artistic practice is in fact ideally suited to articulate this capacity to surprise.

2 thoughts on “Some (very quick) thoughts on Critical Engineering”

A minor quibble: while the term is used somewhat inconsistently, a number of software-studies proponents object to conflating “software studies” with strictly code studies. Some, like Noah Wardrip-Fruin, view the goal of the (sub-)field to be technically informed humanistic study of the logics or processes behind software. From that perspective, reading code is just one method of gaining insight, sometimes more and sometimes less useful or complete.

I wonder if there could be such a thing as “self-opening” code, code that explains it’s own functioning as you use it.

I’m not exactly talking about “chatty” code -although there would inevitably have to be extra information in the UI over and above that needed for it’s function- but something that maps it’s own relationships and interactions as you use it, showing the breakdown of it’s logic and program flow as it works.

For example, imagine a program having a separate window containing a flow chart map that builds up as different parts of the program call each other, starting with the basics that are actually being called in startup and then expanding as you do various things, and having points of highlight that move as the program uses various libraries or UI components, giving you an idea of what the program is doing from use.