It’s time to write up what I’ve been researching this past year. I’m limited to 3000 words, and what’s clear is that there is much more here to discuss, and a lot more detail that I could get into about the question “what are cultural organisations learning from hacker culture”. So here it is, in a compressed form. It does occur to me that this could be developed into something more like a Masters thesis. Or a book.
I’m a hacker.
No, not the kind of hacker that will try to imitate the 80s film Wargames by breaking into military computers, nor one of the Anonymous campaigners who might try to shut down a website they disagree with, nor even a private investigator who might try to break into your phone to listen to your messages.
There’s a definition of the word that’s been in use for just as long that’s about a person who uses technology to rapidly prototype ideas, combining things in creative ways, that’s about taking something apart, combining it with something else and putting it back together again to explore a problem through speed, creativity, technology, remixing and play.
I’m one of those hackers - someone who likes making, experimenting and collaborating by making tiny, quick, digital prototypes. It’s a process that I think could offer cultural organisations a lot, so I’ve spent much of the last year investigating what we’re learning from hacker culture.
Hackdays and Hackathons
A hackday is a period of time (confusingly, often taking up 36 hours) where a diverse group of people assemble, usually unpaid, and usually at a weekend in order to collaborate together in a rapid way around a shared interest. I’ve recently seen or attended hackdays with themes as varied as Science, Sanitation, the NHS, Government, History, Music, Art, Culture, the latter ones being the themes that pushed me to spend some time doing some research on the subject for this paper.
Over recent years there’s been a growth in the number of events marketed as “hackdays” and “hackathons”. I co-organised and attended my first hackday in Birmingham in September 2009. Back then, the idea was that a group of people came together to co-design our own website for the city council (we weren’t very impressed with the newly-built official one). I was inspired by what we achieved in a short space of time and the process we used to rapidly make things, and since then I’ve focussed on “getting good at getting fast”.
The format of a hackday is interesting in itself. People from a diverse background will come together for the day, often with attendees skewed towards those with strong digital making skills - technologists, programmers, user experience specialists, designers, data people and so on.
But the most effective are those events with a good mix of different skillsets and backgrounds. It’s this opportunity to collaborate with new people that is one of the main draws for me to attend events of this kind.
People who work in the cultural sector will be familiar with the idea of “open space” events, where the method for collaborating around ideas is often as simple as a series of conversations and presentations. If you were to imagine an open space event, with a similar “there are no rules” feeling, but with a more directed approach around using the time together to actually make something together, you’d be getting close.
Those working in theatre might also be familiar with Scratch, the rapid approach to creating and performing new work as pioneered by BAC. There are a lot of similarities between a hackday and this approach. The “brief” is given at a pre-event on a Friday evening, work begins in earnest on a Saturday, and continues (often through the night) into Sunday.
At some point during Sunday afternoon the “hacks” that have been made by the teams that have formed in the intervening 36 hours are presented to the other attendees, judges and other invited guests. Sometimes there are prizes for the most creative, funny, useful or interesting things that have been created, sometimes it’s just for the fun of it. In Scratch, work is written and developed rapidly by a team, also over a short period of time, and the results performed to an audience, sometimes followed by an opportunity to hear from them about what they thought.
There’s clearly something interesting and valuable that comes from this rapid feedback approach to developing new work, and the hackday is the digital equivalent.
Duct Tape Programming
It’s only recently that I’ve become comfortable using the word “hacker” to describe how I work. In programming teams you can often find arguments and difficulties emerging from having a “duct tape programmer” on the team, or having written a piece of software that someone else subsequently is given to maintain.
A “duct tape programmer” is the opposite of the person you would want on hand if you had a robust engineering project to tackle. Perhaps a piece of software that controls fuel flow to an engine in an aircraft, or a trading system that must handle many millions of transactions per second between banks.
We solve things messily with digital “duct tape”, often taking cues from the “spikes” - quick, time-boxed pieces of work to answer a question, of Extreme Programming (XP), rather than spending months working out large specification documents. You probably don’t want a hacker working on one of those engineering projects at the point where lives are at stake and the duct tape could come unstuck.
But you do want someone who works rapidly working on a project where you’re not quite sure what it is that you’re trying to do, where there are lots of assumptions that need testing, there are questions that need answering, and where “just getting something on a screen to see whether it might work” is a valid approach.
Culture Hack, Culture Code, Digital Sizzle and a number of other organisations have been organising hackdays aimed at applying this hacking approach to enabling cultural organisations and practitioners to experiment with digital technology. Over the last year I’ve attended many hackdays as a hacker and spoken to a variety of people through informal interviews.
Some of those that I spoke to had the opinion that there was a feeling that the cultural sector is in some ways quite “behind” in its application of digital technologies. The accusation is that “Digital” (whatever that is) is seen as something to be used for marketing purposes - it’s about Facebook pages, blogging, email marketing, ticketing and so on, and not as a way to actually create artistic work or tools that happen to be digital and offer new things to people.
Rachel Coldicutt of Culture Hack spoke recently about what they wanted to achieve with their hackdays: “I was aware of artists not having a way to improvise with digital work. It was becoming very admin heavy and worrying about ticketing and marketing. What we weren’t giving ourselves an opportunity to do was to invent, create and explore… We don’t really have an agenda other than collaborating and creating interesting stuff.”
It’s this improvisatory style that is most refreshing about the approach. I call it Sketching with Code, and I’ve been blogging my research throughout the year: http://sketchingwithcode.com.
Before the hack
Culture Hack is a series of events that brings together organisations with data (or for want of a better word “content” - that could be information, images, video, sound, text, spreadsheets of unusual information) and hackers, in order to explore what could be achieved with what organisations already have to hand.
Katy Beale, also a Culture Hack founder, spoke to me at length about the challenges they face in at first explaining what a hackday is and what an organisation might get from attending a hackday, but also converting the “digital” language of the Open Data movement into something that people understand.
Simply explaining what a hackday is and is not, is a difficult thing. The word “hacking” has become associated with phone-hacking, and there is a certain degree of fear to be overcome. It also needs reiterating that it’s not about getting work done on your website for free.
Through a series of warm-up events, they work with the cultural organisations to understand what they have, cleaning the data and talking through what unexpected things could happen from unexpectedly useful data. As Harry Harold puts it, “developer ready == fit for unexpected reuse”.
This means that once the hackers get involved that there are fewer potential pitfalls that might stop collaboration from being smooth. From a hacker’s point of view this is crucial, and would be a good additional point for the Hackday Manifesto ( http://hackdaymanifesto.com/ ), which is required reading for anyone considering organising a hackday.
Hacks as Art
In the case of Digital Sizzle, they worked in the opposite direction from Culture Hack. As opposed to being from a cultural background, the founders of the event come from the East London tech startup community, and are organisers of events such as Silicon Drinkabout. Their ambitious approach, having never organised a cultural hackday was to partner with the Whitechapel Gallery, on a combined competitive “art hackday” and subsequent exhibition in the gallery.
The invitation process to the event spawned a minor debate about the potential schism caused by inviting “artists” and “geeks” to the event, with some kind of artificial separation implied between the two. This is just a small detail out of the many issues that are involved when organising an event on a shoestring budget, as many hackdays are.
After an intensive period of 36 hours at Mozilla’s (the people who make Firefox, amongst many other things) head quarters, several of the resulting “hack artworks” were exhibited in front of a crowd of some 500 people as a result.
I’d not seen a hackday generate as much interest as this before - there was national press, and the project that I worked on, the Data Necklace - a laser-cut visualisation of your tweets, reached national press in the States, and received offers of funding. But that’s another story. Other hack artworks received corporate funding and the hackers and artists have gone on to work on commissions, including developing and installing one of the works in an airline business class lounge.
For the Whitechapel Gallery, it was a risky experiment - it could have quite easily gone very wrong, and whilst we may not have seen “good art” emerge from the project, it now leaves room for other galleries to do similar experimental work.
Hack, Play Learn
In another project, not produced at a hackday, but described by sound artist Dan Jones as “a great big hack”, he and Peter Gregson collaborated with Britten Sinfonia on a data sonification experiment involving turning Twitter activity into music. The resultant The Listening Machine has had several million listens since it was released on The Space. What’s interesting about this project is the description of it as a “hack” - there was a high degree of experimentation and exploration required to achieve it.
If you’ve read Eric Ries’s book “The Lean Startup”, you will be familiar with his mantra of “Build, Measure, Learn”. This approach advocates building “minimum viable products” (MVPs) which encompass some kind of experiment that will enable you to learn from testing an hypothesis. Which is great, if you know exactly what you want to test, and have access to sufficient resources and time in order to properly test your idea.
I focus on a part that’s not covered by that method - “Hack, Play, Learn”.
At the beginning of a project we don’t have enough information to “measure” anything, so we build a tiny little prototype that we think will be the right thing. Or indeed, we might build several. Hence, the power of a hackday, which lets you parallelise and try out several things at once based on a shared brief.
That’s a very different approach to the traditional “brief, interview, commission” approach that is prevalent in digital commissioning.
Hackdays, Weeks and Months
The criticisms of the hackday are many: they can only lead to bad art, that the results are throwaway, that there’s not long enough to learn from users, amongst many others. These are all valid criticisms and I’ve been struggling with these issues in the hacks that I’ve made during this process: http://stef.io/hacks
The London Review of Books have been involved in a number of hack events this year, and I was lucky to hear about the outcome of Culture Hack East - that it invigorated the staff, there were more ideas being discussed and there was a greater interest in using digital technology in projects.
The hacks that they made at the event were not taking forward into projects. But they were spurred on to do other digital projects, and were successful in gaining funding for a collaboration with Will Self, “Kafka’s Wound” for The Space.
The built-in “failability” of the “hack” can be useful - it’s intentionally a small, tiny experiment, a prototype for something potentially bigger, so you can use it to learn, and once you’ve learnt enough you have the option to throw it away without losing face.
Very occasionally, at something like Startup Weekend, you might see the end result turn into a business, or as I have heard from one hackday attendee, the hack demo could result in an offer of a PhD.
But more often than not the hack will die. And that’s okay.
Many of the people that I spoke to after attending or organising an event were clear - it’s not the end result that’s important, it’s the process.
Extending the hack
So that’s hackdays, but could you have “hack weeks”, or indeed do “hack months” or more? This year, I’ve tried to experience each of these things.
Sync, one part of a strategic approach in Scotland to develop digital capability in cultural organisations invited me to be a Geek in Residence. Their model was to install “creative technologists” in five cultural organisations as you would an artist in residence, in a similar way to the Happenstance project.
Lucy Conway is setting up Eigg Box, on Eigg, one of the Small Isles on the West coast of Scotland and was my host. It’s a “place to make and do” - an environment to focus on a project away from the buzz of the city, but with 50 meg broadband.
I’m effectively “resident” in a field. The building doesn’t yet exist, and I’m the first of a series of residents to visit the island. We’re beta-testing the idea before even the plans for the building are made.
Together with the islanders, we built tiny experiments - a mobile-optimised museum website for the island’s crofting museum, a web-app that helps you run a website using Dropbox, a pay-for digital subscription service for the island’s Fence record label, a history timeline visualisation app, and lots more. For Lucy, our work together was valuable in that it spread the message about what Eigg Box could and would be, both to the islanders and to people who’d visit the island.
Back in London I helped set up the Comic Relief Exploralaboratorium ( http://exploralaboratorium.com ), a trial to rapidly develop ideas that would enable the charity to raise funds all year round. We accepted ideas from the staff and developed them into digital products in five days each.
We had a small team: a designer, a hacker, a product person, and a fixer. To counteract the “throwaway” criticism it was crucial that we had a process to follow through after the initial hack. Each hack had a product owner, backing from director level, and the potential for further funding.
We’re yet to see the full effect of the project, but just from the process so far it’s clear that the staff enjoy the ability to have ideas rapidly tested, and one of the ideas has already received a commitment to be invested in and built into a mobile app. And when that happens, the original hack is thrown away because it’s served its purpose.
With Hoi Polloi I extended the idea over a longer period yet, and we’ve collaborated on Stories from an Invisible Town using an agile, iterative approach that’s also allowed us to do tiny hacks. Bianca Winter, spoke recently about how working in a more “sketchy” and iterative style was a good fit for a theatre company, and allowed for things to grow and change over time, rather than having to specify the end result at the beginning.
Are hacks already going out of fashion?
The density of hackdays reached the point this year where Tom Scott, a geek comedian, half-jokingly declared “peak hack”. There is certainly a danger that with so many hackdays scheduled at weekends, there is more competition, and differentiating one event from another becomes increasingly important.
There is the danger that hackdays could be seen to “have been done”, or “no longer cool”. However, as William Gibson said, “The future is here, it’s just unevenly distributed”. At each of the events I’ve attended I’ve met first-time hackday attendees who’ve gone away inspired, having learnt a different way to think about their work in a digital context, and crucially with a little knowledge on how to take some first steps. Without those first steps, the opportunities presented by other funding bodies in working digitally can feel out of reach.
The Hack as the Message
“For Culture Code it was never about the hacks, it was about the relationships.” - This was Joeli Brearley’s starting point for the hackdays she ran this year in Newcastle.
My main conclusion from my research on cultural hacking is just that - “the hack is the message”.
The “message” that a hack sends is often therefore more important than the hack itself, which may not survive longer than the day it is made in.
For Eigg Box, hacking has helped define what the organisation is all about, for Comic Relief it’s been a way to explore alternative sources of revenue, for attendees of Culture Hack, like the London Review of Books, it’s a way of doing inexpensive digital experiments and sending the message that “we are interested in doing more digital work” which can lead onto commissions and other projects.
All of the cultural hacking projects together act as a crucial set of meeting points between two often quite different groups of people - those who have been working in the cultural sector for some time, and those whose work focusses on digital creativity.
Joeli, Culture Code, makes a strong case, and I summarise from our recent conversation: “I don’t know of any other forum where cultural people can work with digital people as effectively as a hackday”. For her, hackdays offer a unique opportunity for people to have an initial conversation and to take some first steps in doing digital work.
For a sector where there is still a cricism that “we’re behind”, hacking, residencies and iterative projects all could be part of the mix for helping us “get ahead”. None of these approaches is a cure-all, but I will be interested in seeing how they are used over the coming years.
You can read more on Sketching with Code: http://sketchingwithcode.com