What's the point of a hack day if nothing happens after the event?
-16 Aug 2012
- -
-
-Build, Measure, Learn. It's the new mantra adopted by many a tech startup thanks to Eric Ries's influential [The Lean Startup](http://theleanstartup.com).
-
-I've spent a good deal of time over the last few years involved in (more than one) startup. In many ways I'm very grateful for this simple, shorthand phrase to describe the process of taking an idea, seeing if it works, iterating and building a product in an agile way. It's a useful encapsulation of a lot of the processes you go through in a (in my case media/web/software) startup, where code is relatively easy to create, but it's hard to know what the right code to write might be.
-
-The essential process is that given some kind of user problem, you propose a hypothesis or a number of hypotheses around what might be a solution. Then you build as minimal an intervention as possible to test it - it might be a little web app, or making a video to express the idea, or a landing page to see if people might like a product even though it doesn't exist. Then you measure the success of the intervention, and from that measurement you learn about what's working and what isn't. Then you iterate - build, measure, learn, and repeat.
-
-It's a strong idea, and I know a fair few companies who are using this to build digital products - in fact it's almost becoming a dogmatic thing. "What are our learnings?", despite the wince-inducing word-crime, is becoming something of a catch-phrase.
-
-However, looking at the way that I do things, I think that "Build, measure, learn" doesn't fully encompass what's going on when I'm building something.
-
-If the purpose of a startup is to "learn", then of course you can go for the "set a hypothesis, test it" approach, but at the very beginning of a project, way before you have users, I don't see how you can measure anything with any kind of significance.
-
-Also, if you're making a "Minimum Viable Product" (MVP), I'm seeing that a lot of companies, not least ones I've been involved with, spend several months getting to that crucial "put it in front of the users" point. And that leaves plenty of room for startup stories that have a chapter beginning with "it turns out we'd spent all that time building the wrong thing".
-
-Perhaps that's a case of those companies doing it wrong? In the case of the project I'm working on this Summer with a sports brand, the impulse is to hold back on "just get out there" until the app we are building has a decent feature-set that covers a fair amount of what we think users will want it to do. There's a fear that we could damage the project by getting reactions like "this is rubbish" or "it's broken".
-
-The crucial part here is "what we think users will want" - and herein lies the danger. We've run events to talk about our ideas with our target users, taken a sketchy version of our iphone app down to the local skate park (it's a BMX app!) and so on. But we're talking handfuls of users - not the several hundred you'd need to get any kind of statistically relevant results.
-
-It seems to me that much of the lean startup process is based on the idea of applying scientific principles to startups. But I would argue that anyone with a science background would point out that there is far, far too much noise at the beginning of a project to be able to conduct a proper study and gather anything near a "scientific" conclusion.
-
-On talking through that problem I realised that I have a phase that I use that could be usefully applied before you get to that point - "Hack, play, learn".
-
-I like to think of the early days on a project as a sequence of hack days. The idea is not that you will not be able to do anything "scientific" in this phase, but rather that a period of play and experimentation occurs before you can get to the "build, measure, learn" phase.
-
-Children learn through play, and I'd argue that so can adults (in the right conditions). I often think about what I'm doing when I'm hacking on a little idea as play. I'll look at a problem, have some conversations, and often be joking around about what we should do to solve the problem. I've been often surprised that something that starts out with an element of humour tends to lead to very interesting results.
-
-In hack day parlance that's a "comedy hack", and at [Rewired State](http://rewiredstate.org) hack day events you often see that the hacks using a bit of technology with a core idea of something humourous are often the best.
-
-It's this playfulness I try to channel at the very early stages of a project. No, I'm not going to write any tests, or follow Test Driven Development, because what I'm doing is sketching out ideas very quickly (hence "Sketching with Code"), playing with stuff on a screen, and getting something that partially works in front of the other folks on the team to play with, maybe run it past a few "users", but in the main it's just to see what the solution might look like.
-
-I've found that I iterate rapidly around hacking up an idea, playing around with it until I've got something to show, and then taking what I've learnt and applying it to the next iteration. And these iterations are often measured in hours, not days.
-
-The result is a joyful process with rapid results, a team that feels enthused and an accelerated project. But also, I think it means you get to learn a lot right at the beginning that can save a lot of time and money down the line because you're building and failing on things that just aren't right much more rapidly than if you're trying to get something acceptable in front of users and measure their responses.
-
-The "hack, play, learn" phase is often short-lived, and I use it to evaluate project direction. Then, once you've settled on what you're supposed to be doing in the next phase (with a long user journey on post-it-notes on the wall, perhaps), it's time to segue over to "build, measure, learn", throw away that hacky code and build it right.
-
-And "building it right", might include other moments where you need to sketch and evaluate the direction for a new feature or product, in which case jumping back into playful mode is, for me, a good way of achieving it.
-
-I'd be interested to see if other people follow this kind of approach, and hear about anyone who's learnt lessons about the upside and downside to playful approaches to making things.
\ No newline at end of file
diff --git a/blog/_posts/2012-06-01-hack-and-scratch.md b/blog/_posts/2012-06-01-hack-and-scratch.md
deleted file mode 100644
index 35669ba..0000000
--- a/blog/_posts/2012-06-01-hack-and-scratch.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: post
-title: Hack and Scratch
-published: true
-draft: true
----
-In the process of developing a piece of theatre, there's something called "scratch" that I've been introduced to for the first time this year.
-
-Scratch seems to share a few of the properties
\ No newline at end of file
diff --git a/blog/_posts/2012-06-04-loosely-coupled-productivity.md b/blog/_posts/2012-06-04-loosely-coupled-productivity.md
deleted file mode 100644
index 2de8b2e..0000000
--- a/blog/_posts/2012-06-04-loosely-coupled-productivity.md
+++ /dev/null
@@ -1,38 +0,0 @@
----
-layout: post
-title: Loosely-coupled productivity
-published: true
----
-A short conversation on Twitter made me realise something. In early projects I tend towards working in a very loosely-coupled way in order to maximise everyone's productivity. I wonder if there's something to explore here when we think about how hack projects, rapid collaborations and hackdays work best.
-
-Here's the thread:
-
--I don't know about "agile" but Making Things Fast is clearly much easier when you work alone.
— L Johnston (@FinalBullet) June 4, 2012
-@FinalBullet hell yes! Two people in the same room can be super fast too, when in sync.
— Hayden Scott-Baron (@docky) June 4, 2012
-@FinalBullet that's something I've noticed. At hack days if I work alone or very loosely coupled with a designer I actually get things done!
— Stef Lewandowski (@stef) June 4, 2012
-@stef @FinalBullet the first half-day ie crucial: knocking ideas about with people before splitting off to do actual (antisocial) work :)
— Ben O'Steen (@benosteen) June 4, 2012
-@benosteen @stef @docky people who prefer to work in big groups have a kind of moral upper hand, while collaboration is so fashionable but..
— L Johnston (@FinalBullet) June 4, 2012
-@benosteen @stef @docky once i got over the guilt, I realised I'm so clearly hugely more productive alone or with a partner.
— L Johnston (@FinalBullet) June 4, 2012
- -I'm currently working on a project that's a web-app, an API and a (currently iOS only) mobile app. There are lots of moving parts because it's a tool for people to capture, upload, transcode and share short sports videos from their phone. - -Interestingly, because we've got such a strong team of people we've each got trust in the others' abilities to do good work, so my approach for making sure we're productive is to make sure there's a "loosely-coupled" approach not just to the software but to wherever we each overlap. - -So my colleague who's working on the mobile app doesn't have to know how any of the rest of the system works internally - "Just get the video online and send the app the URL" was the starting point, and it was a good way to make sure that as we hacked the prototype together that we didn't block eachother. - -At hackdays I've experienced similar issues. There's a tendency for the day to be about co-creating for teams of several people. Essentially, if you're working with, say, six people, you'd need to go through the "form, storm, norm, perform" cycle in just a handful of hours in order to get something working on a screen - which is a hard task if you've not worked together before. - -For some projects that's exactly what's required - perhaps it's a hard problem, or there are lots of moving parts that need attention from multiple people, but in my own behaviour I've noticed that because I've got a number of things that I've already made, it's often more efficient for me to sit by myself (after working out what to do, but that's a separate post) and blast something out. - -[Chircle](http://chircle.com) is an example of this. I arrived at [CodeAfrica](http://www.thetimes.co.uk/tto/public/codeafrica/article3358455.ece), organised by the Times, and the event was very much geared around the idea of forming teams of several people and everyone working on an idea together. I wasn't in a "chatty" mood - I wanted to make a working app, with an interesting interface, branding, basically the full stack, in a day. I realised that in order to do that much, there wasn't much room for me to share code and design tasks. - -Because hackdays are seen as very collaborative things, it's hard to push back sometimes against the "let's brainstorm" mode that many people think is a good way to kick things off. Personally, I find one interesting conversation with someone who has a problem is the best way to get things going. "Ooh, that's interesting, have you ever thought of ...?" or "Ha! You know what we should do that would be really funny...?" seem to be the things that get me started on a hack. - -But that's not to say that I didn't have help. I had conversations. I asked opinions. I sat with some other folk and chatted about stuff, and made sure I moved around a lot. - -A third example - [Mixilist](http://mixilist.com) - this was a hack I did with [Emily](http://twitter.com/Yummity) at a [Rewired State](http://rewiredstate.org.uk) event. We also had a loosely-coupled approach. I was "building" it, but we were having conversations together, making decisions, thinking about what it should be and why, and Emily was able to produce a brand, graphics and so on, and we had a very light way of working together - she passed me a USB stick or sent an email occasionally! - -So for hackdays and culture-hacks, I'm interested in these things - for many of us is it about the collaboration, the large team approach to working on a problem? Do we get "better" or "more polished" results on hack projects if we keep our teams small (like Mixilist), solo (like Chircle) and/or is there something to be said for having loosely-coupled teams (like my current day-project)? - -Perhaps the term "loosely-coupled productivity" is over-egging a simple idea, but it might be something I bear in mind next time I'm throwing together a quick hack, or doing a collaboration to explore an idea. \ No newline at end of file diff --git a/blog/_posts/2012-06-27-the-hack-as-the-message.md b/blog/_posts/2012-06-27-the-hack-as-the-message.md deleted file mode 100644 index e243e03..0000000 --- a/blog/_posts/2012-06-27-the-hack-as-the-message.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -layout: post -title: The Hack as the Message -published: true -draft: false ---- -Is the hack what matters, or is it the message that you can send by doing the hack that's the important thing? - -I've been spending time looking at cultural hacks, attending events and talking to people who work in this way, and I've noticed three groups of hacks that I'd like to talk about: - -## Playful hacks - -Attend one of the Culture Hack Days and you'll see a bunch of enjoyable, fun little hacks being made in a 36hr period. These are often throwaway little ideas to demonstrate the beginning of an idea, ideas that point towards the "proximate possible", or experiments with some new data/tool/API that's become available. - -## Art hacks - -These are subtly different, where people who self identify as artists create works of art that have a "hacking" component - altering the urban landscape in some way, doing things at the edges of legality, interfering with the way that things work in interesting ways. The recent Hack the City exhibition at Dublin's Science Gallery is a good example of this kind of work - interpreting the interventions that these hacks represent as works of art. - -## Hacks that get backed - -Then there are more developed pieces of work that start out as hacks, but through additional resources being put behind their development turn into larger-scale prototypes that can be put in front of a larger audience. [Peter Gregson](http://petergregson.co.uk), [London Sinfonietta](http://www.londonsinfonietta.org.uk/) and [Dan Jones](https://twitter.com/#!/ideoforms/) collaborated on the widely appreciated [Listening Machine](http://www.thelisteningmachine.org/) for [The Space](http://thespace.org/) and Dan Jones when I spoke to him explained that he thought of the whole project as an "uber-hack". They'd taken a hack and extended it into a longer-term piece of work that resulted in a finished thing. - -## The message - -It's quite artificial to divide up hacks into categories in this way, and I don't want to suggest that it's a good idea to pigeon-hole people's work, but I wanted to talk about something I've noticed that seems to apply across all three. - -It's "the hack as the message". - -I'm interested in the idea that it's not the actual hack that's important - to the person making it and the organisation/person/city whose data/service/object is being hacked, it's the fact that the hack is a message to others about what is possible. - -Hackers are flexing creative muscles and in so doing sending a message about their availability for that kind of work (so it's partly a promotion thing), but also they're sending a message to other cultural and creative organisations about what could, or should, be done - with their data, with their assets, with the kinds of things they do, and in collaboration with people who have experience of making things in this way. - -I think there's a perception amongst both the cultural people and the hackers who attend Culture Hack, for example, that the cultural sector is somehow "playing catch-up" and needs to "embrace digital". I also think that because the idea of "embracing digital" is so abstract, that through these small hacks we can demonstrate tiny little ideas without the risk of wasting public money or R&D budgets. - -I'm not sure it's true to say that the cultural sector as a whole is playing catch up - perhaps I need to look into this a little more - but certainly I've seen the surprise and delight of people who've come away from a [Culture Hack Day](http://culturehackday.org.uk) with a very different idea of what can be achieved with technology. - -Taking the example of [Hack the City](http://sciencegallery.com/hackthecity), I saw hacks presented as works of art, playing around with what can be adjusted in cities, often pushing boundaries of legality (surveillance drones, gaffer-tape street games, adjusting news websites when viewed over a particular network and so on ). Through these kinds of hack we're seeing people playing around with what's coming and what's next and pre-empting the kinds of questions that we're going to be asking ten years from now. That's a different kind of message - the "what do you think of what's happening now, and what's going to be possible soon?" and "look how easy it is to make these interventions, you can do it yourself". - -With "hacks that get backed" (and I've worked on a few!) we're moving from the realm of "little demonstrator" to "something that people actually use". And here the message is subtly different. This is that "working in a hacky way we can make valuable things", "hacks aren't just throw-away things", "through rapid experimentation we can take an idea to a product", and so on. - -Message received? I suspect that'll be a future post. - -*Disclosure* I've worked with [Caper](http://wearecaper.com), who started Culture Hack Day, on a paid basis in the past, although we're not working on anything together at the moment. I'm building a mashup site for [Peter Gregson](http://petergregson.co.uk). diff --git a/blog/_posts/2012-06-29-dont-organise-a-hack-day.md b/blog/_posts/2012-06-29-dont-organise-a-hack-day.md deleted file mode 100644 index 3a8b31f..0000000 --- a/blog/_posts/2012-06-29-dont-organise-a-hack-day.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -layout: post -title: Don't organise a hack day -published: true -draft: true ---- \ No newline at end of file diff --git a/blog/_posts/2012-06-30-learning-driven-development.md b/blog/_posts/2012-06-30-learning-driven-development.md deleted file mode 100644 index 35fe004..0000000 --- a/blog/_posts/2012-06-30-learning-driven-development.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -layout: post -title: Learning Driven Development -published: true -draft: true ---- -Test Driven Development (TDD), Behaviour Driven Development (BDD), Business Driven Development... there's plenty of "Driven Developments" - -Here's another to add to the list, that I've been thinking about recently: "Learning Driven Development". - -TDD is a software development methodology that aims to improve software quality by requiring the developer to write automated tests before they write the code that fulfils the requirements of the tests. The typical flow is "get a requirement", "write a test for the first step to fulfilling the requirement", "run the test", "watch it fail", "write the smallest amount of code required to fulfil the test", "run it again", "watch it pass", "refactor the code as required" (Refactoring being the process of rewriting, reorganising code for a variety of reasons). In this way, you ensure that you're only writing the bare minimum of code required to do the thing that is required, you have code that is documented (the tests become your documentation), and your application should be robust and easy to pass on to another developer should you need to. - -BDD takes this a step forward and deals with the behaviours of users. In BDD we talk at a higher level about different types of users, what these users want to achieve and how we might measure the success of these things. Typically, we're able to write very similar tests to what we would in TDD but with an added "human-understandable" layer on top. For an apple website we might see "In order to sell more apples, as a potential customer I can get one apple free with each dozen that I add to my basket", which implies all sorts of features - a "basket", a "deal", a "customer", some way of representing "apples", some way of representing multiples of apples, and so on. But the crucial thing is that the actual feature is tied to the business goal or behaviour we want to support. \ No newline at end of file diff --git a/blog/_posts/2012-07-05-culture-hack-east-2012-video.md b/blog/_posts/2012-07-05-culture-hack-east-2012-video.md deleted file mode 100644 index 93c59e4..0000000 --- a/blog/_posts/2012-07-05-culture-hack-east-2012-video.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -layout: post -title: Culture Hack East 2012 (Video) -published: true ---- - - -I recently hacked at [Culture Hack East](http://www.creativefront.org/news-and-events/news/photos-from-culture-hack-east-2012), and the folks at [Project Trident](http://projecttrident.com) were there making a short [video of the day](http://vimeo.com/45129897). I think this sums up a lot of what happens at a cultural hack day, so I'll leave it at that, other than to say "I've finished my first hack... I'm going to make another" sums up a lot! \ No newline at end of file diff --git a/blog/_posts/2012-07-19-eiggbox-geeks-in-residence.md b/blog/_posts/2012-07-19-eiggbox-geeks-in-residence.md deleted file mode 100644 index 4063d1d..0000000 --- a/blog/_posts/2012-07-19-eiggbox-geeks-in-residence.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -layout: post -title: Beginning my Eiggbox Geek-in-residency -published: true ---- - -Hacking an island? ------------------- - -It's not often you get an opportunity to do that, so I'm pretty excited about going to the Scottish island of [Eigg](http://isleofeigg.org) and being one of the first [geeks in residence](www.welcometosync.com/geeks/) on Sync's new cultural/technology project. - -Here's a collection of initial thoughts about what I might do with my time, a bit about my process, and what I hope will come out of my time at (the as-yet purely virtual) [Eigg Box](http://eiggbox.com). - -Why am I doing this? --------------------- - -I've just come out of working very hard for three years on [a web video startup](http://aframe.com) (I didn't design the sales site btw). For the uninitiated, have a read of the [#startuplife](http://twitter.com/search?q=startuplife) hashtag on twitter. Long hours, too much coffee, lots of ups and downs, but a singular focus on doing one thing really well and getting a successful business off the ground. We did just that, raised a good amount of investment, and it was time for me to change modes. - -My new thing is "playfully hacking on things that matter", and I'm spending my time throwing the net wide, doing a variety of interesting projects with a variety of interesting people. Here's a bit about what that means... - -"Playful", as in not really worrying too much about the end results of making something being something that could turn into a business, or having some idea of an immediate return on investment. I like to approach things with a bit of humour, lightness and just the beginnings of an idea on what could happen, then let conversations and play determine the result. - -"Hacking", as in the positive use of the word, not doing illegal things, has been getting a bit of attention recently as a way of rapidly experimenting with solutions to problems, or to learn about something in a "take it apart and put it back together again" way. - -I've spent the last few years getting good at making digital things really quickly. You'll often find me at "hack days", where people get together to make interesting little experiments over a short period of time, often around 36 hours. I'm researching this stuff at [Sketching with Code](http://sketchingwithcode.com) and you can see [some of the things I've hacked together in the past](http://stef.io/hacks). - -And "things that matter", as in projects that have some kind of output other than just "make lots of money", or "solve a first world problem for people with iPhones". I gave a talk recently at the inagural [Find Better Problems](http://findbetterproblems.com) event, and it seems that a fair few people are getting a little tired of people working in technology focussing all their efforts on getting people to see more ads, buy virtual products for an online game or work out a way to compete with Tim Berners Lee's "Anything you can do I can do meta". - -I think there's a lot that cultural organisations can learn from creative technologists who work in this way, and vice versa, so I'm bringing this "playfully hacking on things that matter" idea to Eigg, and I'm keeping my mind open to what might happen as a result. - -Today, I start my journey from London, and I'll be spending the weekend meeting Lucy and friends, talking to [Suzy](http://triggerstuff.co.uk) about some of the ideas that are floating around, coming up with others, and we'll probably have a few hacks to show by the time I come back on Tuesday. \ No newline at end of file diff --git a/blog/_posts/2012-07-24-starting-my-geek-in-residency.md b/blog/_posts/2012-07-24-starting-my-geek-in-residency.md deleted file mode 100644 index 9613528..0000000 --- a/blog/_posts/2012-07-24-starting-my-geek-in-residency.md +++ /dev/null @@ -1,80 +0,0 @@ ---- -layout: post -title: Being a hacker on a remote Scottish island -published: true ---- - - - -Wow. Well that certainly was an experience I'll remember. I've just come back from my first trip to [Eigg](http://isleofeigg.org) and I shall seemingly be known, I hope affectionately, as "Our Geek" by the fascinating array of folk I met while I was there. - -For some of the next few months I will be spending time both on the island and at home working as a Geek in Residence there. - -Lucy, who is setting up the perfectly-named [Eigg Box](http://eiggbox.co.uk) as a new cultural centre for the island arranged for my first visit to coincide with Scottish indie label Fence Records's second festival on the island. So my first impressions are going to be of a much more populous Hebridean island than for most on their first visit. - -The plan for my residency was to head over, sit with Lucy for the weekend and work out some ideas, themes, problems, hacks, projects that we could work on later on in the year when I return. - -In contrast to the other four residencies that are taking place, Eigg Box is currently in the"what a good idea" stage. There's no building, only the beginnings of a business plan, no real funding and no staff other than Lucy. But what the project lacks in physical and financial assets it makes up for with bucket loads of support from the islanders, strong vision and leadership from Lucy and a "community needs first" approach that reminds me of Alex, one of the early proponents of the coworking movement who set up the successful Indie Hall in Philadelphia. - -The island is fascinating and the more I heard about its history the more fascinating it got. With around forty households and around ninety people living there, it's a tiny place. So within a couple of days (and thanks to the festival for pulling everyone together) I'd had bonfire-side chats with probably half of the people who live there, and they're a diverse, resourceful, creative and inspirational bunch! I'm looking forward to spending more time with them on my return in September. - -Until then I'm probably going to get stuck into a hack or two, think a little more about the themes that emerged in the conversations that emerged when Suzy Glass joined us for the last couple of days. - -We're quite deliberately keeping all of this quite open. We've had too many good ideas that we could try to do together, and we're not yet at the point where we should be narrowing down onto single achievable pieces of work. I suspect what's needed now is in the comfort of home (I was rescuing collapsing wind-blown tents on Sunday morning!) I'll sketch up some of the following: - - - -Telling the story of Eigg -------------------------- - -Camille, one of the islanders who was living there's during the famous community buyout, where the island effectively did a Kickstarter and raised enough money to buy an entire island, is the local historian. She's researched and published a book of the island's history (sadly out of print - candidate for on demand / turning into an e-book?) as well as turning two buildings into museums, and a ton of other cultural work. I'm hoping that I can bring an (appropriate) level of digital thinking to amplify the effort she has already put in. - -I'm thinking simple audio tours for mobile devices, so new visitors can download it using the wifi at the cafe by the dock and then wander the island. Proceeds from app sales perhaps going to her history projects. - -Also, there's an archive of clippings that could do with digitising, some support getting a site online that she can maintain without my involvement, timelines, family trees, lots of stuff to do! - -Helping get Eigg Box off the ground ------------------------------------ - -Because the Eigg Box idea is so early, there's some obvious work that I could do in helping communicate the idea of what it is going to be in order to help gain funding, interest and support from finders, sponsors, residents, potential overseas visitors, and so on. - -Many people think of me as a software developer nowadays, which I find quite funny because my first company was a design agency, so I shall probably help with some branding help, materials pack (or indeed using some of my budget to buy an off the shelf branding pack that we could adapt). Again, the idea is that I leave behind something useful that doesn't require external support. - -Helping make life easier with appropriate tech ----------------------------------------------- - -There are a few little problems that emerged during my time there. And with a little hack or two we could make some interesting sketches for solutions that might solve them, making life on Eigg a little easier for residents and visitors. - -Transport can be problematic, and even finding a way to connect up the required train/plane/car/ferry connections is time consuming. Perhaps we could sketch up a wiki where people can share their journey plans, or even a journey calculator. - -Also, there's no cash point on the island, yet there are entrepreneurs providing services. Could we use [Gocardless](http://gocardless.com), [Square](http://squareup.com) (or the UK equivalent), perhaps some kind of hotel tab card and a way to tally up how much a visitor spends and dividing up a single payment between the various intended recipients? - -There's one of the islanders who knows about how to build websites, but I can imagine there being a bit of a bottleneck (I know - I've been it in the past!), and I've heard a few stories about projects that went awry when working with other web people from elsewhere in the country. I suspect finding ways for people to very simply operate the web side of their businesses using really easy tools. I've found an iPad app [Simpl](http://itunes.apple.com/gb/app/simpl/id506609825?mt=8) (not the [FutureGov](http://wearefuturegov.com/) project) that looks great for that kind of thing. Plus there are a couple of iPads on the island. - -Sharing knowledge ------------------ - -And then there's just a piece of work to be done about having good conversations with folk, giving a few pointers, and swapping them for interesting and useful things that I can learn and take away. - - - -Making something physical -------------------------- - -I'm currently really interested in 3d printing, laser cutting and short run manufacturing. One or two of the islanders and I joked about making an Eigg Coop that would be an open source, easy to replicate/print chicken coop. Could be a nice experiment! - - - -Playful, fun stuff ------------------- - -Of course I'll also be making some fun little things. Stuff with instagram, stuff with Flickr, little sketches of ideas, who knows. The guiding principle at the moment is to keep it wide and undefined, until such a time as one or two turn into something promising. Then I shall probably work with Lucy to decide on where to put the effort, where to focus and hopefully end up with some lasting, useful tools that help Eigg Box get to the next stage. - - - -Remoteness ----------- - -Finally, I put the word "remote" in the title of this post on purpose. I loved the work that [Distance Lab](http://www.distancelab.org) did a few years ago, so there may be a thing or two to do around similar themes. - -I'll end by summarising Lucy's wise words on the subject - "everywhere is remote from somewhere". \ No newline at end of file diff --git a/blog/_posts/2012-07-24-the-word-hacking.md b/blog/_posts/2012-07-24-the-word-hacking.md deleted file mode 100644 index 08a895a..0000000 --- a/blog/_posts/2012-07-24-the-word-hacking.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -layout: post -title: Using the Word "Hacking" -published: true ---- -The word "hack" can confuse people who've not come across it before, other than in the context of a "hacker" doing something illegal or malevolent, and as a result, the term "hack day" can be quite scary. - -Last year I attended National Hack the Government day with Rewired State. It's a day for people to play around with open data sources provided by data.gov.uk and others, to experiment and play with what's possible now that we have such a large number of data sets open to us. - -Amusingly, the sign on the door had omitted a crucial word, and read "National Government Day", presumably because someone, somewhere had lost their nerve or misunderstood what it was all about. - -I think that fear of "hack", "hacker" and "hacking" isn't something to be ignored. I also think that it might be potentially unhelpful in enabling people in any organisation to do the "internal sales" piece in order to get a hack day to happen, or to propose more experimental ways of working with digital media and technology. - -I regularly find myself having to explain that if I say I'm a hacker, I don't mean of the evil kind, and that it's a different thing entirely. I'd be laughably bad as a real hacker, I'm sure, although in my work it's important to know a bit about web security so that you can protect against all but the most serious of "real" hackers. As I've learnt, as a result, anyone who tells you anything is absolutely secure is wrong. - -I think that that fear of hackers is only growing as a result of the press that Anonymous, Lulzsec and others have been getting, as well as the barrage of password security fails, virus alerts, phishing scams, and general internet nastiness that we all have to learn to navigate around daily. So it's no wonder that suggesting (the other type of) hackers and cultural folk get together to do interesting things is met with a little confusion and trepidation. - -If we, as hackers (of the hackday attendee variety), are advocating playful, experimental, creative approach to working with technology, I do wonder if the term "hack" is limiting our ability to do that. So perhaps, by using "hack" as a term, we're deliberately limiting how mainstream this approach could one day be? Is the real idea that hacking should always be on the periphery and the province of the maverick, inventor, geek? - -Perhaps that's why I've used the phrase "sketching with code" for this project - It might be that I wanted to talk to a wider audience than those who would feel comfortable reading about "hacking", so I omitted the word "hack" unconsciously. - -If not "hack" and "hacker", then what could we use as an alternative shorthand? "Creative technologist" has been doing the rounds for a long time, and I know some people who self-identify with that term successfully, so perhaps that's adequate to a degree. - -Yet I struggle to find that noun for the rapidly-produced, quickly-knocked-together demonstrator, or the verb for taking things apart and putting them together in an interesting or unexpected way. - -I suspect I am doomed to be that guy at the dinner party who gets a wide eyed response from the person sitting next to him when asked "so what do you do?" \ No newline at end of file diff --git a/blog/_posts/2012-08-13-demonstrable-productivity-over-time.md b/blog/_posts/2012-08-13-demonstrable-productivity-over-time.md deleted file mode 100644 index 562a104..0000000 --- a/blog/_posts/2012-08-13-demonstrable-productivity-over-time.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -layout: post -title: A graph of demonstrable productivity over time -published: true -draft: true ---- - diff --git a/blog/_posts/2012-08-14-who-owns-the-hack.md b/blog/_posts/2012-08-14-who-owns-the-hack.md deleted file mode 100644 index 25461a8..0000000 --- a/blog/_posts/2012-08-14-who-owns-the-hack.md +++ /dev/null @@ -1,76 +0,0 @@ ---- -layout: post -title: Who owns the hack? -published: true -draft: false ---- - -Attend any hack day or hackathon and at some point someone will ask a question about ownership over a hack - the software and design that has gone into its production, any data/APIs that it uses, and any pre-existing stuff (software libraries, things copied and pasted from previous projects, etc.) used in its creation. - -Each event is different and will have its own set of guidelines. Here are a few observations about the different kinds of licensing and ownership issues you might need consider at a hack day. - -Note: I'm not a lawyer, and this isn't legal advice! If you're having an issue with licensing post-hack you should get some proper legal advice from an IP specialist. - -## By default - -Unless some other agreement is made, copyright on code and designs are retained by whoever makes the hack. You can't copyright an idea, but if you have a team of people making it, it's generally understood that "anything new" is owned collectively by the team until some other agreement is made, and that people own the rights for "anything old" that they have created previously that they use in making the hack. - -Any data used in the hack is under whatever licence the data provider grants for the hack, but that doesn't mean they automatically get any rights over the resulting hack. Sometimes at hack days pre-released, time-limited or non-commercial-only data licences apply. That's usually to prevent a situation where a data provider could inadvertently close down a future commercial opportunity by "giving it away for free" and serves to remove a potential risk. If you're a data provider, have a conversation with the organiser about a usage agreement you'd be happy with. - -## Full ownership by the organiser or sponsor - -Occasionally a hack day will be organised specifically for a company to learn and the attendees will be paid for their time. If that's the case then sometimes the intellectual property to the results of the event will be retained by the organiser or sponsor. Essentially, the idea is that it's a "paid-for hack", equivalent to a day of freelance consultancy, so this is a perfectly legitimate approach. You might find at some of these events that the results aren't made public, and the source code is not released publicly either. - -## All hacks under the same licence - -I've seen a handful of hackdays advertise in advance (one just hit my inbox) that all of the hacks will be released under a specific licence - usually one of the many Creative Commons licences. I'd be interested in talking to the organisers of these events because I can see a number of problems and benefits with applying a blanket licence. - -If you're intending on organising such a day, I'd advise saying well in advance (in the announcement for the event) that a (for example) CC licence would apply, because it could avoid any embarrassing or difficult conversations on the day. - -Using a creative commons licence for a hack day is admirable - what you're saying is that you hope that the results of the day can be used by others to do interesting things in the future, and that the effect of the day is maximised by ensuring wide dissemination of the hacks. - -However, given that hack days are very short in duration, attendees will have spend a lot of time getting fast at starting from scratch in order to complete something within a short space of time. So they will tend to be bringing along a lot of code that they have used before. Does this licence include that other work? I can't see how it can't, given that the code will end up on GitHub with a CC0 licence applied to it. - -As an example, an upcoming [Wellcome Trust game-hack](http://www.wellcome.ac.uk/Funding/Public-engagement/Funded-projects/Major-initiatives/Broadcast-media-strategy/Gamify-Your-PhD/WTDV033976.htm) requires pre-formed teams of games designers and developers to attend an event where their work will be released under creative commons. In order to produce a good game in a short space of time, a developer will be reaching for code they've written before. I can't personally see the justification for applying that CC licence to the pre-written code used in the making of the hack. - -So as an attendee I have two options (assuming I want to attend) - release anything that I've made in the past under this new licence, or don't use my existing stuff and start completely form scratch. It comes down to how fast you want to be able to work, and whether you are ok with releasing your stuff because the organisers say so. - -Another issue is that, let's assume you've made a really great hack and there is a large amount of interest in it after the hack day. Would having released the code under a creative commons licence mean that you might not be able to get funding for the idea? Would that count as you being "naive" in the eyes of a potential investor..? I don't, but it sounds like a risk. - -Obviously, code written at a hack day is likely to be pretty low quality, pragmatism-over-idealism stuff and it could be argued that it therefore has low value. However if you wanted to get investment and to do so meant deleting your hack and starting again from scratch, that's not an attractive idea for most people. - -Personally I find it a bit of a blunt approach. I'd much rather have a "suggested" licence, and if you're unhappy for some reason, apply whatever licence you like. Indeed, I did this with Chircle, because I saw that it might have potential to be an interesting product rather that just a hack. - -## Whatever licence you like - -In general, most hack days that I've attended use this approach. In fact, the majority of hacks probably don't have any kind of licence applied. My preference is to copy and paste the standard MIT licence and put it in a readme (assuming I want to request the code, which I do most of the time). This licence means that the hacker retains copyright but that anyone is free to use it, even for commercial projects. - -## In conclusion - -It's worth thinking through the reasoning for whatever licensing approach you might have chosen for your hack day, and including a short paragraph somewhere explaining it, especially for paid-for hacks, or ones where you wish to apply a blanket licence. - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/blog/_posts/2012-08-15-preparing-your-data-for-a-hack-day.md b/blog/_posts/2012-08-15-preparing-your-data-for-a-hack-day.md deleted file mode 100644 index b6f3e9d..0000000 --- a/blog/_posts/2012-08-15-preparing-your-data-for-a-hack-day.md +++ /dev/null @@ -1,71 +0,0 @@ ---- -layout: post -title: Preparing your data for a hack day -published: true -draft: false ---- - -In advance of the more well-planned hack days I've seen recently, one of the new ideas that they have been trying out is organising pre-event workshops and events for the organisations who will be supplying data for the main hack event. - -There seem to be a few reasons for doing this: - -## Explanation - -It's still unclear to many people who work in cultural organisations what a hack day is all about, so it is important that people from a wide variety of organisations are invited along, told about how it works, what it is all about, and what the general principles are. This is important so that problems that might emerge on the day can be fixed in advance, and that everyone is clear what the scope of the hack is. Eg. No, someone won't sort out your website for free, but they might, if you can supply some interesting and unique data, look at doing a prototype of a mobile app that fulfils a certain purpose. - -## Opening data - -[Katy Beale](http://flavors.me/katybeale), one of the [Culture Hack](http://twitter.com/culturehack) team, surprised me by saying that many potential attendees aren't really aware that they have "data". This might be because people think of data as some kind of abstract, complicated thing that's stored in a big database somewhere. - -At a pre-event workshop, they spend a fair amount of time talking about what data is, and working with the cultural organisations to think about the kinds of a information they are already keeping for reporting and transparency reasons - footfall, postcode from where a visitor travelled, box office takings, usage of parts of a building, all sorts of stuff that might otherwise be ignored. Katy described a lightbulb moment that some people experienced when they realised that information they were already recording could be turned into something else at the hack day, without too much work on their part. - -## Data cleaning - -I've been along to many hack days where the data that is provided for us to play with is only just about good enough, and there is always a frustrated comment or two when it emerges that what at first hand appeared to be a good set of standardised data would have really strange anomalies in it which would mean that some poor soul would spend half their time on the hack day manually going through a speed sheet making it consistent so that their hack would work without bombing. - -Part of the advanced work that Culture Hack do is to work with the organisations to look through the array of spreadsheets, text files, folders of images and so on in order to work out how "clean" the data is, and then to recommend anything that might need to be done by the cultural organisations to prepare it for the day. - -Here's a few examples of data cleaning issues I've seen that could have prevented a hack day fail: - -### Supplying a massive database dump in a proprietary format - -For instance, your web development team give you a Microsoft SQL Server file that is several gigabytes in size, and gives you a link for where someone could access it. The problem here is that nobody has really looked at what it contains, and worse, it means that anybody who wants to see what it contains must download the massive file, have double or triple that in available space on their hard drive, also have a licence for that particular software (in the hundreds or low thousands of pounds, dependent on the format), and have the patience to do all of this too! - -Aim to provide data in free formats such as CSV, JSON, TXT, or XML, and provide a small subset of the data in advance do that potential hackers can get a feel for what is in the data. - -### Excel documents where business logic is described as formulae - -Complex Excel files are almost impossible to work with on a hack day - it just takes too long to work out the relationships between things, plus you're also relying on those present to have a paid-for licence for the software (I don't, for instance). Sometimes it is quite helpful to look through an excel spreadsheet and be a be able to look at the formulae involved. The trouble is, that if this gets complicated it is very hard to extract that logic out of the document and make other things that rely on the same relationships between things. - -If possible, find a way to supply any important business logic as a human readable explanatory document. - -### Documents where the text colour or background colour of things is important - -I've seen lots of spreadsheets where people use red, orange and yellow background fills to denote some kind of status about something. Whilst that is useful for a person to be able to get an overview of the statuses of those things in one glance, it's quite a bit of work for me as someone who wants to do something with that information on to be able to extract it. Assuming I know Excel (which I don't very much), I'd have to write some kind of function that takes the colour of those columns and puts a value in another column somewhere. It might even not be clear what those values might equate to - what might orange mean? - -Far better to have these colours in their own column in th first place, and then I can export the data as I want it for my hack. - -### Inconsistencies in the data - -Addresses are tricky - which column might the postcode appear in? Or perhaps in your export you are using "comma separated values" (CSV) but whatever does the export doesn't know what to do if the there are bits of text containing commas. - -Or a field that has "Happy" as a value, but sometimes is shortened to "H" or "HAP" or "happy" or "4/5" or "4" or "\*\*\*\*", or perhaps after a certain date it is left blank and assumed to be "happy". You can imagine the trouble - how can I write a program that uses that value, unless I manually go through every row in the data to "normalise" it to a single, standard way of describing that value. And let's say there a few of these inconsistencies... I'm going to give up and hack on something else, sadly! - -So in advance, it's worth cleaning up the data, making sure things are consistent and explained. - -## Thinking about rights - -At some point the conversation about who owns what, as the result of a hack day, will come up. Some of the work that hack day organisers can do in advance is to discuss the kinds of rights agreements that might be made, from the point of view of the organisations and their ownership of data and derivative works; from the point of view of the hacker and the ownership of and copyright over the code they write and any improvements they might make to the data; from the point of view of the organisers and any general principles they put in place in advance of the event (everything will be open sourced under a creative commons licence, for instance), and also from the position of whoever the hack might be for - the users. - -There are a few thorny issues here, so I shall cover this some more in another post. - -## Planning for the hack - -I find it interesting that hack days have matured to the point where we are now looking at how to ensure that participants on both sides get the most from the day. What's more, I saw definite improvements in the quality of the data that came through at the latest Culture Hack, and indeed that seems to be happening at other hack days too. - -Planning for the hack, or setting things up so that good things come from a unique combination of talents is a smart idea. I'm looking forward to learning about other things that people are doing to ensure hack days go smoothly. - - - - - diff --git a/blog/_posts/2012-08-16-after-the-hack.md b/blog/_posts/2012-08-16-after-the-hack.md deleted file mode 100644 index d0dfdfc..0000000 --- a/blog/_posts/2012-08-16-after-the-hack.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -layout: post -title: What's the point of a hack day if nothing happens after the event? -status: published -draft: false ---- - -A question I was asked today, and it got me thinking. Attend a good hack day and you will see tens of hacks presented in the final rounding-up session, but how many of these prototypes and sketches go on to be developed further, turned into real products and services, companies even? - -Does it matter if the answer is "well, pretty much none of them!"? - -Anecdotally I'd say that the vast majority of hacks produced at hack days tend to fall by the wayside and do not receive any further development after the day. However, there do seem to be a small proportion that are taken forward, gain investment (in the broad sense of eye word) and end up as extra features of an existing product, or products and services in their own right. - -I've noticed recently, that whereas many hackdays and latterly hackathons started out as days for experimentation and exploration we are now seeing them being used as a way for companies to find and acquire talent, and one of the things put to potential attendees is the idea that if they're lucky, and their hack is "good enough" then they will get a chance to present their idea to a handful of influential and powerful investors/industry people. Perhaps with a suggestion that their hack could get some seed funding to turn it from a hack into an investable proposition, gain some additional funds to turn it into a prototype, or just straight up get the attention of these important people in order to get a first/better job. - -I think that this is probably a strong motivator for young hackers and designers - to get the "break" they've always been hoping for, and that's an admirable thing to hope to achieve for your attendees as a hack day organiser. - -However, putting some kind of promise of a "prize" at the core of the event, I feel, alters it and turns it away from a playful, fun, collaborative event into one that is much more serious, competitive and siloed. I know the feeling from first hand experiences, having attended non-competitive hack days versus as well as ones that have an element of competition. - -I'm quite competitive, so even if the prize is basically my day rate for two days' work, I'd be pretty motivated to make sure I 'win' (whatever that means!). The trouble is, that in doing so you end up closing down and not collaborating helpfully with those around you, as much as you might have done had the competition element not been part of the mix. - -For that reason, I'm not a big fan of "big prize" hack days, where teams of people who already work together go to an event to show how wonderful they are against all the other company teams. Gone is the element of playful collaboration, learning and exploration that I find so exciting about hack days. - -I guess that's why I find the term "hackathon" irritating - I have a (probably incorrect) mental connection between "hackathon" and "competitive hacking event" versus "hackday" and "collaborative hacking event". \ No newline at end of file diff --git a/blog/_site/2012/05/26/hacker-culture/index.html b/blog/_site/2012/05/26/hacker-culture/index.html deleted file mode 100644 index a27bcaf..0000000 --- a/blog/_site/2012/05/26/hacker-culture/index.html +++ /dev/null @@ -1,22 +0,0 @@ -@FinalBullet @benosteen @stef Absolutely! Best collabs have been a programmer designer lead, assistant artist, and auxiliary sound person.
— Hayden Scott-Baron (@docky) June 4, 2012
For the past few years I’ve immersed myself in the world of hack days, and become pretty interested in collaboratations between hackers and artists / cultural organisations.
- -Not “hacker” in the sense of someone who does something evil to a bank’s website, but rather “hacker” in the sense of someone who sees a problem, rapidly develops a quick solution in a playful, creative way, often with technology.
- -I now self-identify as a hacker (of the second variety), and have been attending hack days where software people, designers and organisations with interesting open data get together to innovate in public, in teams that form on the day, always with surprising, funny and inspirational results. Examples of these events are Culture Hack Day, National Hack the Government Day, Rewired State and Culture Hack Scotland.
- -This kind of open innovation has been seen in the cultural sector in the open space event format for some time, but the crucial extension is that these events and processes result in rapid development of digital and technology-based ideas and can be used to validate a variety of ideas before one or two are developed into actual products, services or cultural works.
- -We are now beginning to see many more cultural organisations applying these techniques not just for one off events, but looking at how to enable more long-term projects within their organisations with “hacker in residence” programmes, open data initiatives and adopting agile/lean methodologies for digital projects.
- -It’s early days, but I can see some new thinking emerging here. If you’re a cultural organisation and you’re excited by hacker culture and what could be achieved through open innovation and open data what are the actions you should take in order to embrace it? What projects are leading the way in applying these principles in successful ways? What does “success” mean in the context of cultural hacking? Do hack days lead to actual tangible results, or is it more about shifting a mind-set about what is possible with digital tools?
- -Nesta and the Clore Leadership Programme have given me a small amount of research money to enable me to have conversations with people involved in and interested in these kinds of things, so I’m starting this site to pull together whatever comes out of the process along the way.
- -By November I’ll have written up a short paper about what I’ve learnt, which I’ll be presenting at a Nesta event, and it’ll be published in a collection with a number of others.
- -In the spirit of openness, I’ve built this site using a mashup of Padrino and Jekyll, which is probably a bit crazy, but it does give me more freedom than a Tumblr/Posterous/Wordpress thing. I’ve put the source code on github too.
- -Please leave a comment if you’d like to chat about these things over a coffee!
diff --git a/blog/_site/2012/05/29/hack-play-learn/index.html b/blog/_site/2012/05/29/hack-play-learn/index.html deleted file mode 100644 index 50c6c85..0000000 --- a/blog/_site/2012/05/29/hack-play-learn/index.html +++ /dev/null @@ -1,43 +0,0 @@ -
-Build, Measure, Learn. It’s the new mantra adopted by many a tech startup thanks to Eric Ries’s influential The Lean Startup.
- -I’ve spent a good deal of time over the last few years involved in (more than one) startup. In many ways I’m very grateful for this simple, shorthand phrase to describe the process of taking an idea, seeing if it works, iterating and building a product in an agile way. It’s a useful encapsulation of a lot of the processes you go through in a (in my case media/web/software) startup, where code is relatively easy to create, but it’s hard to know what the right code to write might be.
- -The essential process is that given some kind of user problem, you propose a hypothesis or a number of hypotheses around what might be a solution. Then you build as minimal an intervention as possible to test it - it might be a little web app, or making a video to express the idea, or a landing page to see if people might like a product even though it doesn’t exist. Then you measure the success of the intervention, and from that measurement you learn about what’s working and what isn’t. Then you iterate - build, measure, learn, and repeat.
- -It’s a strong idea, and I know a fair few companies who are using this to build digital products - in fact it’s almost becoming a dogmatic thing. “What are our learnings?”, despite the wince-inducing word-crime, is becoming something of a catch-phrase.
- -However, looking at the way that I do things, I think that “Build, measure, learn” doesn’t fully encompass what’s going on when I’m building something.
- -If the purpose of a startup is to “learn”, then of course you can go for the “set a hypothesis, test it” approach, but at the very beginning of a project, way before you have users, I don’t see how you can measure anything with any kind of significance.
- -Also, if you’re making a “Minimum Viable Product” (MVP), I’m seeing that a lot of companies, not least ones I’ve been involved with, spend several months getting to that crucial “put it in front of the users” point. And that leaves plenty of room for startup stories that have a chapter beginning with “it turns out we’d spent all that time building the wrong thing”.
- -Perhaps that’s a case of those companies doing it wrong? In the case of the project I’m working on this Summer with a sports brand, the impulse is to hold back on “just get out there” until the app we are building has a decent feature-set that covers a fair amount of what we think users will want it to do. There’s a fear that we could damage the project by getting reactions like “this is rubbish” or “it’s broken”.
- -The crucial part here is “what we think users will want” - and herein lies the danger. We’ve run events to talk about our ideas with our target users, taken a sketchy version of our iphone app down to the local skate park (it’s a BMX app!) and so on. But we’re talking handfuls of users - not the several hundred you’d need to get any kind of statistically relevant results.
- -It seems to me that much of the lean startup process is based on the idea of applying scientific principles to startups. But I would argue that anyone with a science background would point out that there is far, far too much noise at the beginning of a project to be able to conduct a proper study and gather anything near a “scientific” conclusion.
- -On talking through that problem I realised that I have a phase that I use that could be usefully applied before you get to that point - “Hack, play, learn”.
- -I like to think of the early days on a project as a sequence of hack days. The idea is not that you will not be able to do anything “scientific” in this phase, but rather that a period of play and experimentation occurs before you can get to the “build, measure, learn” phase.
- -Children learn through play, and I’d argue that so can adults (in the right conditions). I often think about what I’m doing when I’m hacking on a little idea as play. I’ll look at a problem, have some conversations, and often be joking around about what we should do to solve the problem. I’ve been often surprised that something that starts out with an element of humour tends to lead to very interesting results.
- -In hack day parlance that’s a “comedy hack”, and at Rewired State hack day events you often see that the hacks using a bit of technology with a core idea of something humourous are often the best.
- -It’s this playfulness I try to channel at the very early stages of a project. No, I’m not going to write any tests, or follow Test Driven Development, because what I’m doing is sketching out ideas very quickly (hence “Sketching with Code”), playing with stuff on a screen, and getting something that partially works in front of the other folks on the team to play with, maybe run it past a few “users”, but in the main it’s just to see what the solution might look like.
- -I’ve found that I iterate rapidly around hacking up an idea, playing around with it until I’ve got something to show, and then taking what I’ve learnt and applying it to the next iteration. And these iterations are often measured in hours, not days.
- -The result is a joyful process with rapid results, a team that feels enthused and an accelerated project. But also, I think it means you get to learn a lot right at the beginning that can save a lot of time and money down the line because you’re building and failing on things that just aren’t right much more rapidly than if you’re trying to get something acceptable in front of users and measure their responses.
- -The “hack, play, learn” phase is often short-lived, and I use it to evaluate project direction. Then, once you’ve settled on what you’re supposed to be doing in the next phase (with a long user journey on post-it-notes on the wall, perhaps), it’s time to segue over to “build, measure, learn”, throw away that hacky code and build it right.
- -And “building it right”, might include other moments where you need to sketch and evaluate the direction for a new feature or product, in which case jumping back into playful mode is, for me, a good way of achieving it.
- -I’d be interested to see if other people follow this kind of approach, and hear about anyone who’s learnt lessons about the upside and downside to playful approaches to making things.
diff --git a/blog/_site/2012/06/01/hack-and-scratch/index.html b/blog/_site/2012/06/01/hack-and-scratch/index.html deleted file mode 100644 index 63f55d5..0000000 --- a/blog/_site/2012/06/01/hack-and-scratch/index.html +++ /dev/null @@ -1,6 +0,0 @@ -In the process of developing a piece of theatre, there’s something called “scratch” that I’ve been introduced to for the first time this year.
- -Scratch seems to share a few of the properties
diff --git a/blog/_site/2012/06/04/loosely-coupled-productivity/index.html b/blog/_site/2012/06/04/loosely-coupled-productivity/index.html deleted file mode 100644 index 1b8561d..0000000 --- a/blog/_site/2012/06/04/loosely-coupled-productivity/index.html +++ /dev/null @@ -1,28 +0,0 @@ -A short conversation on Twitter made me realise something. In early projects I tend towards working in a very loosely-coupled way in order to maximise everyone’s productivity. I wonder if there’s something to explore here when we think about how hack projects, rapid collaborations and hackdays work best.
- -Here’s the thread:
-I don't know about "agile" but Making Things Fast is clearly much easier when you work alone.
— L Johnston (@FinalBullet) June 4, 2012
@FinalBullet hell yes! Two people in the same room can be super fast too, when in sync.
— Hayden Scott-Baron (@docky) June 4, 2012
@FinalBullet that's something I've noticed. At hack days if I work alone or very loosely coupled with a designer I actually get things done!
— Stef Lewandowski (@stef) June 4, 2012
@stef @FinalBullet the first half-day ie crucial: knocking ideas about with people before splitting off to do actual (antisocial) work :)
— Ben O'Steen (@benosteen) June 4, 2012
@benosteen @stef @docky people who prefer to work in big groups have a kind of moral upper hand, while collaboration is so fashionable but..
— L Johnston (@FinalBullet) June 4, 2012
@benosteen @stef @docky once i got over the guilt, I realised I'm so clearly hugely more productive alone or with a partner.
— L Johnston (@FinalBullet) June 4, 2012
-@FinalBullet @benosteen @stef Absolutely! Best collabs have been a programmer designer lead, assistant artist, and auxiliary sound person.
— Hayden Scott-Baron (@docky) June 4, 2012
I’m currently working on a project that’s a web-app, an API and a (currently iOS only) mobile app. There are lots of moving parts because it’s a tool for people to capture, upload, transcode and share short sports videos from their phone.
- -Interestingly, because we’ve got such a strong team of people we’ve each got trust in the others’ abilities to do good work, so my approach for making sure we’re productive is to make sure there’s a “loosely-coupled” approach not just to the software but to wherever we each overlap.
- -So my colleague who’s working on the mobile app doesn’t have to know how any of the rest of the system works internally - “Just get the video online and send the app the URL” was the starting point, and it was a good way to make sure that as we hacked the prototype together that we didn’t block eachother.
- -At hackdays I’ve experienced similar issues. There’s a tendency for the day to be about co-creating for teams of several people. Essentially, if you’re working with, say, six people, you’d need to go through the “form, storm, norm, perform” cycle in just a handful of hours in order to get something working on a screen - which is a hard task if you’ve not worked together before.
- -For some projects that’s exactly what’s required - perhaps it’s a hard problem, or there are lots of moving parts that need attention from multiple people, but in my own behaviour I’ve noticed that because I’ve got a number of things that I’ve already made, it’s often more efficient for me to sit by myself (after working out what to do, but that’s a separate post) and blast something out.
- -Chircle is an example of this. I arrived at CodeAfrica, organised by the Times, and the event was very much geared around the idea of forming teams of several people and everyone working on an idea together. I wasn’t in a “chatty” mood - I wanted to make a working app, with an interesting interface, branding, basically the full stack, in a day. I realised that in order to do that much, there wasn’t much room for me to share code and design tasks.
- -Because hackdays are seen as very collaborative things, it’s hard to push back sometimes against the “let’s brainstorm” mode that many people think is a good way to kick things off. Personally, I find one interesting conversation with someone who has a problem is the best way to get things going. “Ooh, that’s interesting, have you ever thought of …?” or “Ha! You know what we should do that would be really funny…?” seem to be the things that get me started on a hack.
- -But that’s not to say that I didn’t have help. I had conversations. I asked opinions. I sat with some other folk and chatted about stuff, and made sure I moved around a lot.
- -A third example - Mixilist - this was a hack I did with Emily at a Rewired State event. We also had a loosely-coupled approach. I was “building” it, but we were having conversations together, making decisions, thinking about what it should be and why, and Emily was able to produce a brand, graphics and so on, and we had a very light way of working together - she passed me a USB stick or sent an email occasionally!
- -So for hackdays and culture-hacks, I’m interested in these things - for many of us is it about the collaboration, the large team approach to working on a problem? Do we get “better” or “more polished” results on hack projects if we keep our teams small (like Mixilist), solo (like Chircle) and/or is there something to be said for having loosely-coupled teams (like my current day-project)?
- -Perhaps the term “loosely-coupled productivity” is over-egging a simple idea, but it might be something I bear in mind next time I’m throwing together a quick hack, or doing a collaboration to explore an idea.
diff --git a/blog/_site/2012/06/27/the-hack-as-the-message/index.html b/blog/_site/2012/06/27/the-hack-as-the-message/index.html deleted file mode 100644 index 9e108fb..0000000 --- a/blog/_site/2012/06/27/the-hack-as-the-message/index.html +++ /dev/null @@ -1,40 +0,0 @@ -Is the hack what matters, or is it the message that you can send by doing the hack that’s the important thing?
- -I’ve been spending time looking at cultural hacks, attending events and talking to people who work in this way, and I’ve noticed three groups of hacks that I’d like to talk about:
- -Attend one of the Culture Hack Days and you’ll see a bunch of enjoyable, fun little hacks being made in a 36hr period. These are often throwaway little ideas to demonstrate the beginning of an idea, ideas that point towards the “proximate possible”, or experiments with some new data/tool/API that’s become available.
- -These are subtly different, where people who self identify as artists create works of art that have a “hacking” component - altering the urban landscape in some way, doing things at the edges of legality, interfering with the way that things work in interesting ways. The recent Hack the City exhibition at Dublin’s Science Gallery is a good example of this kind of work - interpreting the interventions that these hacks represent as works of art.
- -Then there are more developed pieces of work that start out as hacks, but through additional resources being put behind their development turn into larger-scale prototypes that can be put in front of a larger audience. Peter Gregson, London Sinfonietta and Dan Jones collaborated on the widely appreciated Listening Machine for The Space and Dan Jones when I spoke to him explained that he thought of the whole project as an “uber-hack”. They’d taken a hack and extended it into a longer-term piece of work that resulted in a finished thing.
- -It’s quite artificial to divide up hacks into categories in this way, and I don’t want to suggest that it’s a good idea to pigeon-hole people’s work, but I wanted to talk about something I’ve noticed that seems to apply across all three.
- -It’s “the hack as the message”.
- -I’m interested in the idea that it’s not the actual hack that’s important - to the person making it and the organisation/person/city whose data/service/object is being hacked, it’s the fact that the hack is a message to others about what is possible.
- -Hackers are flexing creative muscles and in so doing sending a message about their availability for that kind of work (so it’s partly a promotion thing), but also they’re sending a message to other cultural and creative organisations about what could, or should, be done - with their data, with their assets, with the kinds of things they do, and in collaboration with people who have experience of making things in this way.
- -I think there’s a perception amongst both the cultural people and the hackers who attend Culture Hack, for example, that the cultural sector is somehow “playing catch-up” and needs to “embrace digital”. I also think that because the idea of “embracing digital” is so abstract, that through these small hacks we can demonstrate tiny little ideas without the risk of wasting public money or R&D budgets.
- -I’m not sure it’s true to say that the cultural sector as a whole is playing catch up - perhaps I need to look into this a little more - but certainly I’ve seen the surprise and delight of people who’ve come away from a Culture Hack Day with a very different idea of what can be achieved with technology.
- -Taking the example of Hack the City, I saw hacks presented as works of art, playing around with what can be adjusted in cities, often pushing boundaries of legality (surveillance drones, gaffer-tape street games, adjusting news websites when viewed over a particular network and so on ). Through these kinds of hack we’re seeing people playing around with what’s coming and what’s next and pre-empting the kinds of questions that we’re going to be asking ten years from now. That’s a different kind of message - the “what do you think of what’s happening now, and what’s going to be possible soon?” and “look how easy it is to make these interventions, you can do it yourself”.
- -With “hacks that get backed” (and I’ve worked on a few!) we’re moving from the realm of “little demonstrator” to “something that people actually use”. And here the message is subtly different. This is that “working in a hacky way we can make valuable things”, “hacks aren’t just throw-away things”, “through rapid experimentation we can take an idea to a product”, and so on.
- -Message received? I suspect that’ll be a future post.
- -Disclosure I’ve worked with Caper, who started Culture Hack Day, on a paid basis in the past, although we’re not working on anything together at the moment. I’m building a mashup site for Peter Gregson.
diff --git a/blog/_site/2012/06/29/dont-organise-a-hack-day/index.html b/blog/_site/2012/06/29/dont-organise-a-hack-day/index.html deleted file mode 100644 index 301a558..0000000 --- a/blog/_site/2012/06/29/dont-organise-a-hack-day/index.html +++ /dev/null @@ -1,4 +0,0 @@ -Test Driven Development (TDD), Behaviour Driven Development (BDD), Business Driven Development… there’s plenty of “Driven Developments”
- -Here’s another to add to the list, that I’ve been thinking about recently: “Learning Driven Development”.
- -TDD is a software development methodology that aims to improve software quality by requiring the developer to write automated tests before they write the code that fulfils the requirements of the tests. The typical flow is “get a requirement”, “write a test for the first step to fulfilling the requirement”, “run the test”, “watch it fail”, “write the smallest amount of code required to fulfil the test”, “run it again”, “watch it pass”, “refactor the code as required” (Refactoring being the process of rewriting, reorganising code for a variety of reasons). In this way, you ensure that you’re only writing the bare minimum of code required to do the thing that is required, you have code that is documented (the tests become your documentation), and your application should be robust and easy to pass on to another developer should you need to.
- -BDD takes this a step forward and deals with the behaviours of users. In BDD we talk at a higher level about different types of users, what these users want to achieve and how we might measure the success of these things. Typically, we’re able to write very similar tests to what we would in TDD but with an added “human-understandable” layer on top. For an apple website we might see “In order to sell more apples, as a potential customer I can get one apple free with each dozen that I add to my basket”, which implies all sorts of features - a “basket”, a “deal”, a “customer”, some way of representing “apples”, some way of representing multiples of apples, and so on. But the crucial thing is that the actual feature is tied to the business goal or behaviour we want to support.
diff --git a/blog/_site/2012/07/05/culture-hack-east-2012-video/index.html b/blog/_site/2012/07/05/culture-hack-east-2012-video/index.html deleted file mode 100644 index bac4f12..0000000 --- a/blog/_site/2012/07/05/culture-hack-east-2012-video/index.html +++ /dev/null @@ -1,5 +0,0 @@ -I recently hacked at Culture Hack East, and the folks at Project Trident were there making a short video of the day. I think this sums up a lot of what happens at a cultural hack day, so I’ll leave it at that, other than to say ”I’ve finished my first hack… I’m going to make another” sums up a lot!
diff --git a/blog/_site/2012/07/19/eiggbox-geeks-in-residence/index.html b/blog/_site/2012/07/19/eiggbox-geeks-in-residence/index.html deleted file mode 100644 index 46d5e49..0000000 --- a/blog/_site/2012/07/19/eiggbox-geeks-in-residence/index.html +++ /dev/null @@ -1,26 +0,0 @@ -It’s not often you get an opportunity to do that, so I’m pretty excited about going to the Scottish island of Eigg and being one of the first geeks in residence on Sync’s new cultural/technology project.
- -Here’s a collection of initial thoughts about what I might do with my time, a bit about my process, and what I hope will come out of my time at (the as-yet purely virtual) Eigg Box.
- -I’ve just come out of working very hard for three years on a web video startup (I didn’t design the sales site btw). For the uninitiated, have a read of the #startuplife hashtag on twitter. Long hours, too much coffee, lots of ups and downs, but a singular focus on doing one thing really well and getting a successful business off the ground. We did just that, raised a good amount of investment, and it was time for me to change modes.
- -My new thing is “playfully hacking on things that matter”, and I’m spending my time throwing the net wide, doing a variety of interesting projects with a variety of interesting people. Here’s a bit about what that means…
- -“Playful”, as in not really worrying too much about the end results of making something being something that could turn into a business, or having some idea of an immediate return on investment. I like to approach things with a bit of humour, lightness and just the beginnings of an idea on what could happen, then let conversations and play determine the result.
- -“Hacking”, as in the positive use of the word, not doing illegal things, has been getting a bit of attention recently as a way of rapidly experimenting with solutions to problems, or to learn about something in a “take it apart and put it back together again” way.
- -I’ve spent the last few years getting good at making digital things really quickly. You’ll often find me at “hack days”, where people get together to make interesting little experiments over a short period of time, often around 36 hours. I’m researching this stuff at Sketching with Code and you can see some of the things I’ve hacked together in the past.
- -And “things that matter”, as in projects that have some kind of output other than just “make lots of money”, or “solve a first world problem for people with iPhones”. I gave a talk recently at the inagural Find Better Problems event, and it seems that a fair few people are getting a little tired of people working in technology focussing all their efforts on getting people to see more ads, buy virtual products for an online game or work out a way to compete with Tim Berners Lee’s “Anything you can do I can do meta”.
- -I think there’s a lot that cultural organisations can learn from creative technologists who work in this way, and vice versa, so I’m bringing this “playfully hacking on things that matter” idea to Eigg, and I’m keeping my mind open to what might happen as a result.
- -Today, I start my journey from London, and I’ll be spending the weekend meeting Lucy and friends, talking to Suzy about some of the ideas that are floating around, coming up with others, and we’ll probably have a few hacks to show by the time I come back on Tuesday.
diff --git a/blog/_site/2012/07/24/starting-my-geek-in-residency/index.html b/blog/_site/2012/07/24/starting-my-geek-in-residency/index.html deleted file mode 100644 index fd587a8..0000000 --- a/blog/_site/2012/07/24/starting-my-geek-in-residency/index.html +++ /dev/null @@ -1,70 +0,0 @@ -
Wow. Well that certainly was an experience I’ll remember. I’ve just come back from my first trip to Eigg and I shall seemingly be known, I hope affectionately, as “Our Geek” by the fascinating array of folk I met while I was there.
- -For some of the next few months I will be spending time both on the island and at home working as a Geek in Residence there.
- -Lucy, who is setting up the perfectly-named Eigg Box as a new cultural centre for the island arranged for my first visit to coincide with Scottish indie label Fence Records’s second festival on the island. So my first impressions are going to be of a much more populous Hebridean island than for most on their first visit.
- -The plan for my residency was to head over, sit with Lucy for the weekend and work out some ideas, themes, problems, hacks, projects that we could work on later on in the year when I return.
- -In contrast to the other four residencies that are taking place, Eigg Box is currently in the”what a good idea” stage. There’s no building, only the beginnings of a business plan, no real funding and no staff other than Lucy. But what the project lacks in physical and financial assets it makes up for with bucket loads of support from the islanders, strong vision and leadership from Lucy and a “community needs first” approach that reminds me of Alex, one of the early proponents of the coworking movement who set up the successful Indie Hall in Philadelphia.
- -The island is fascinating and the more I heard about its history the more fascinating it got. With around forty households and around ninety people living there, it’s a tiny place. So within a couple of days (and thanks to the festival for pulling everyone together) I’d had bonfire-side chats with probably half of the people who live there, and they’re a diverse, resourceful, creative and inspirational bunch! I’m looking forward to spending more time with them on my return in September.
- -Until then I’m probably going to get stuck into a hack or two, think a little more about the themes that emerged in the conversations that emerged when Suzy Glass joined us for the last couple of days.
- -We’re quite deliberately keeping all of this quite open. We’ve had too many good ideas that we could try to do together, and we’re not yet at the point where we should be narrowing down onto single achievable pieces of work. I suspect what’s needed now is in the comfort of home (I was rescuing collapsing wind-blown tents on Sunday morning!) I’ll sketch up some of the following:
- -
Camille, one of the islanders who was living there’s during the famous community buyout, where the island effectively did a Kickstarter and raised enough money to buy an entire island, is the local historian. She’s researched and published a book of the island’s history (sadly out of print - candidate for on demand / turning into an e-book?) as well as turning two buildings into museums, and a ton of other cultural work. I’m hoping that I can bring an (appropriate) level of digital thinking to amplify the effort she has already put in.
- -I’m thinking simple audio tours for mobile devices, so new visitors can download it using the wifi at the cafe by the dock and then wander the island. Proceeds from app sales perhaps going to her history projects.
- -Also, there’s an archive of clippings that could do with digitising, some support getting a site online that she can maintain without my involvement, timelines, family trees, lots of stuff to do!
- -Because the Eigg Box idea is so early, there’s some obvious work that I could do in helping communicate the idea of what it is going to be in order to help gain funding, interest and support from finders, sponsors, residents, potential overseas visitors, and so on.
- -Many people think of me as a software developer nowadays, which I find quite funny because my first company was a design agency, so I shall probably help with some branding help, materials pack (or indeed using some of my budget to buy an off the shelf branding pack that we could adapt). Again, the idea is that I leave behind something useful that doesn’t require external support.
- -There are a few little problems that emerged during my time there. And with a little hack or two we could make some interesting sketches for solutions that might solve them, making life on Eigg a little easier for residents and visitors.
- -Transport can be problematic, and even finding a way to connect up the required train/plane/car/ferry connections is time consuming. Perhaps we could sketch up a wiki where people can share their journey plans, or even a journey calculator.
- -Also, there’s no cash point on the island, yet there are entrepreneurs providing services. Could we use Gocardless, Square (or the UK equivalent), perhaps some kind of hotel tab card and a way to tally up how much a visitor spends and dividing up a single payment between the various intended recipients?
- -There’s one of the islanders who knows about how to build websites, but I can imagine there being a bit of a bottleneck (I know - I’ve been it in the past!), and I’ve heard a few stories about projects that went awry when working with other web people from elsewhere in the country. I suspect finding ways for people to very simply operate the web side of their businesses using really easy tools. I’ve found an iPad app Simpl (not the FutureGov project) that looks great for that kind of thing. Plus there are a couple of iPads on the island.
- -And then there’s just a piece of work to be done about having good conversations with folk, giving a few pointers, and swapping them for interesting and useful things that I can learn and take away.
- -
I’m currently really interested in 3d printing, laser cutting and short run manufacturing. One or two of the islanders and I joked about making an Eigg Coop that would be an open source, easy to replicate/print chicken coop. Could be a nice experiment!
- -
Of course I’ll also be making some fun little things. Stuff with instagram, stuff with Flickr, little sketches of ideas, who knows. The guiding principle at the moment is to keep it wide and undefined, until such a time as one or two turn into something promising. Then I shall probably work with Lucy to decide on where to put the effort, where to focus and hopefully end up with some lasting, useful tools that help Eigg Box get to the next stage.
- -
Finally, I put the word “remote” in the title of this post on purpose. I loved the work that Distance Lab did a few years ago, so there may be a thing or two to do around similar themes.
- -I’ll end by summarising Lucy’s wise words on the subject - “everywhere is remote from somewhere”.
diff --git a/blog/_site/2012/07/24/the-word-hacking/index.html b/blog/_site/2012/07/24/the-word-hacking/index.html deleted file mode 100644 index 3b301b5..0000000 --- a/blog/_site/2012/07/24/the-word-hacking/index.html +++ /dev/null @@ -1,24 +0,0 @@ -The word “hack” can confuse people who’ve not come across it before, other than in the context of a “hacker” doing something illegal or malevolent, and as a result, the term “hack day” can be quite scary.
- -Last year I attended National Hack the Government day with Rewired State. It’s a day for people to play around with open data sources provided by data.gov.uk and others, to experiment and play with what’s possible now that we have such a large number of data sets open to us.
- -Amusingly, the sign on the door had omitted a crucial word, and read “National Government Day”, presumably because someone, somewhere had lost their nerve or misunderstood what it was all about.
- -I think that fear of “hack”, “hacker” and “hacking” isn’t something to be ignored. I also think that it might be potentially unhelpful in enabling people in any organisation to do the “internal sales” piece in order to get a hack day to happen, or to propose more experimental ways of working with digital media and technology.
- -I regularly find myself having to explain that if I say I’m a hacker, I don’t mean of the evil kind, and that it’s a different thing entirely. I’d be laughably bad as a real hacker, I’m sure, although in my work it’s important to know a bit about web security so that you can protect against all but the most serious of “real” hackers. As I’ve learnt, as a result, anyone who tells you anything is absolutely secure is wrong.
- -I think that that fear of hackers is only growing as a result of the press that Anonymous, Lulzsec and others have been getting, as well as the barrage of password security fails, virus alerts, phishing scams, and general internet nastiness that we all have to learn to navigate around daily. So it’s no wonder that suggesting (the other type of) hackers and cultural folk get together to do interesting things is met with a little confusion and trepidation.
- -If we, as hackers (of the hackday attendee variety), are advocating playful, experimental, creative approach to working with technology, I do wonder if the term “hack” is limiting our ability to do that. So perhaps, by using “hack” as a term, we’re deliberately limiting how mainstream this approach could one day be? Is the real idea that hacking should always be on the periphery and the province of the maverick, inventor, geek?
- -Perhaps that’s why I’ve used the phrase “sketching with code” for this project - It might be that I wanted to talk to a wider audience than those who would feel comfortable reading about “hacking”, so I omitted the word “hack” unconsciously.
- -If not “hack” and “hacker”, then what could we use as an alternative shorthand? “Creative technologist” has been doing the rounds for a long time, and I know some people who self-identify with that term successfully, so perhaps that’s adequate to a degree.
- -Yet I struggle to find that noun for the rapidly-produced, quickly-knocked-together demonstrator, or the verb for taking things apart and putting them together in an interesting or unexpected way.
- -I suspect I am doomed to be that guy at the dinner party who gets a wide eyed response from the person sitting next to him when asked “so what do you do?”
diff --git a/blog/_site/2012/08/13/demonstrable-productivity-over-time/index.html b/blog/_site/2012/08/13/demonstrable-productivity-over-time/index.html deleted file mode 100644 index e954a39..0000000 --- a/blog/_site/2012/08/13/demonstrable-productivity-over-time/index.html +++ /dev/null @@ -1,4 +0,0 @@ -Attend any hack day or hackathon and at some point someone will ask a question about ownership over a hack - the software and design that has gone into its production, any data/APIs that it uses, and any pre-existing stuff (software libraries, things copied and pasted from previous projects, etc.) used in its creation.
- -Each event is different and will have its own set of guidelines. Here are a few observations about the different kinds of licensing and ownership issues you might need consider at a hack day.
- -Note: I’m not a lawyer, and this isn’t legal advice! If you’re having an issue with licensing post-hack you should get some proper legal advice from an IP specialist.
- -Unless some other agreement is made, copyright on code and designs are retained by whoever makes the hack. You can’t copyright an idea, but if you have a team of people making it, it’s generally understood that “anything new” is owned collectively by the team until some other agreement is made, and that people own the rights for “anything old” that they have created previously that they use in making the hack.
- -Any data used in the hack is under whatever licence the data provider grants for the hack, but that doesn’t mean they automatically get any rights over the resulting hack. Sometimes at hack days pre-released, time-limited or non-commercial-only data licences apply. That’s usually to prevent a situation where a data provider could inadvertently close down a future commercial opportunity by “giving it away for free” and serves to remove a potential risk. If you’re a data provider, have a conversation with the organiser about a usage agreement you’d be happy with.
- -Occasionally a hack day will be organised specifically for a company to learn and the attendees will be paid for their time. If that’s the case then sometimes the intellectual property to the results of the event will be retained by the organiser or sponsor. Essentially, the idea is that it’s a “paid-for hack”, equivalent to a day of freelance consultancy, so this is a perfectly legitimate approach. You might find at some of these events that the results aren’t made public, and the source code is not released publicly either.
- -I’ve seen a handful of hackdays advertise in advance (one just hit my inbox) that all of the hacks will be released under a specific licence - usually one of the many Creative Commons licences. I’d be interested in talking to the organisers of these events because I can see a number of problems and benefits with applying a blanket licence.
- -If you’re intending on organising such a day, I’d advise saying well in advance (in the announcement for the event) that a (for example) CC licence would apply, because it could avoid any embarrassing or difficult conversations on the day.
- -Using a creative commons licence for a hack day is admirable - what you’re saying is that you hope that the results of the day can be used by others to do interesting things in the future, and that the effect of the day is maximised by ensuring wide dissemination of the hacks.
- -However, given that hack days are very short in duration, attendees will have spend a lot of time getting fast at starting from scratch in order to complete something within a short space of time. So they will tend to be bringing along a lot of code that they have used before. Does this licence include that other work? I can’t see how it can’t, given that the code will end up on GitHub with a CC0 licence applied to it.
- -As an example, an upcoming Wellcome Trust game-hack requires pre-formed teams of games designers and developers to attend an event where their work will be released under creative commons. In order to produce a good game in a short space of time, a developer will be reaching for code they’ve written before. I can’t personally see the justification for applying that CC licence to the pre-written code used in the making of the hack.
- -So as an attendee I have two options (assuming I want to attend) - release anything that I’ve made in the past under this new licence, or don’t use my existing stuff and start completely form scratch. It comes down to how fast you want to be able to work, and whether you are ok with releasing your stuff because the organisers say so.
- -Another issue is that, let’s assume you’ve made a really great hack and there is a large amount of interest in it after the hack day. Would having released the code under a creative commons licence mean that you might not be able to get funding for the idea? Would that count as you being “naive” in the eyes of a potential investor..? I don’t, but it sounds like a risk.
- -Obviously, code written at a hack day is likely to be pretty low quality, pragmatism-over-idealism stuff and it could be argued that it therefore has low value. However if you wanted to get investment and to do so meant deleting your hack and starting again from scratch, that’s not an attractive idea for most people.
- -Personally I find it a bit of a blunt approach. I’d much rather have a “suggested” licence, and if you’re unhappy for some reason, apply whatever licence you like. Indeed, I did this with Chircle, because I saw that it might have potential to be an interesting product rather that just a hack.
- -In general, most hack days that I’ve attended use this approach. In fact, the majority of hacks probably don’t have any kind of licence applied. My preference is to copy and paste the standard MIT licence and put it in a readme (assuming I want to request the code, which I do most of the time). This licence means that the hacker retains copyright but that anyone is free to use it, even for commercial projects.
- -It’s worth thinking through the reasoning for whatever licensing approach you might have chosen for your hack day, and including a short paragraph somewhere explaining it, especially for paid-for hacks, or ones where you wish to apply a blanket licence.
diff --git a/blog/_site/2012/08/15/preparing-your-data-for-a-hack-day/index.html b/blog/_site/2012/08/15/preparing-your-data-for-a-hack-day/index.html deleted file mode 100644 index 62b1db2..0000000 --- a/blog/_site/2012/08/15/preparing-your-data-for-a-hack-day/index.html +++ /dev/null @@ -1,62 +0,0 @@ -In advance of the more well-planned hack days I’ve seen recently, one of the new ideas that they have been trying out is organising pre-event workshops and events for the organisations who will be supplying data for the main hack event.
- -There seem to be a few reasons for doing this:
- -It’s still unclear to many people who work in cultural organisations what a hack day is all about, so it is important that people from a wide variety of organisations are invited along, told about how it works, what it is all about, and what the general principles are. This is important so that problems that might emerge on the day can be fixed in advance, and that everyone is clear what the scope of the hack is. Eg. No, someone won’t sort out your website for free, but they might, if you can supply some interesting and unique data, look at doing a prototype of a mobile app that fulfils a certain purpose.
- -Katy Beale, one of the Culture Hack team, surprised me by saying that many potential attendees aren’t really aware that they have “data”. This might be because people think of data as some kind of abstract, complicated thing that’s stored in a big database somewhere.
- -At a pre-event workshop, they spend a fair amount of time talking about what data is, and working with the cultural organisations to think about the kinds of a information they are already keeping for reporting and transparency reasons - footfall, postcode from where a visitor travelled, box office takings, usage of parts of a building, all sorts of stuff that might otherwise be ignored. Katy described a lightbulb moment that some people experienced when they realised that information they were already recording could be turned into something else at the hack day, without too much work on their part.
- -I’ve been along to many hack days where the data that is provided for us to play with is only just about good enough, and there is always a frustrated comment or two when it emerges that what at first hand appeared to be a good set of standardised data would have really strange anomalies in it which would mean that some poor soul would spend half their time on the hack day manually going through a speed sheet making it consistent so that their hack would work without bombing.
- -Part of the advanced work that Culture Hack do is to work with the organisations to look through the array of spreadsheets, text files, folders of images and so on in order to work out how “clean” the data is, and then to recommend anything that might need to be done by the cultural organisations to prepare it for the day.
- -Here’s a few examples of data cleaning issues I’ve seen that could have prevented a hack day fail:
- -For instance, your web development team give you a Microsoft SQL Server file that is several gigabytes in size, and gives you a link for where someone could access it. The problem here is that nobody has really looked at what it contains, and worse, it means that anybody who wants to see what it contains must download the massive file, have double or triple that in available space on their hard drive, also have a licence for that particular software (in the hundreds or low thousands of pounds, dependent on the format), and have the patience to do all of this too!
- -Aim to provide data in free formats such as CSV, JSON, TXT, or XML, and provide a small subset of the data in advance do that potential hackers can get a feel for what is in the data.
- -Complex Excel files are almost impossible to work with on a hack day - it just takes too long to work out the relationships between things, plus you’re also relying on those present to have a paid-for licence for the software (I don’t, for instance). Sometimes it is quite helpful to look through an excel spreadsheet and be a be able to look at the formulae involved. The trouble is, that if this gets complicated it is very hard to extract that logic out of the document and make other things that rely on the same relationships between things.
- -If possible, find a way to supply any important business logic as a human readable explanatory document.
- -I’ve seen lots of spreadsheets where people use red, orange and yellow background fills to denote some kind of status about something. Whilst that is useful for a person to be able to get an overview of the statuses of those things in one glance, it’s quite a bit of work for me as someone who wants to do something with that information on to be able to extract it. Assuming I know Excel (which I don’t very much), I’d have to write some kind of function that takes the colour of those columns and puts a value in another column somewhere. It might even not be clear what those values might equate to - what might orange mean?
- -Far better to have these colours in their own column in th first place, and then I can export the data as I want it for my hack.
- -Addresses are tricky - which column might the postcode appear in? Or perhaps in your export you are using “comma separated values” (CSV) but whatever does the export doesn’t know what to do if the there are bits of text containing commas.
- -Or a field that has “Happy” as a value, but sometimes is shortened to “H” or “HAP” or “happy” or “4/5” or “4” or “****”, or perhaps after a certain date it is left blank and assumed to be “happy”. You can imagine the trouble - how can I write a program that uses that value, unless I manually go through every row in the data to “normalise” it to a single, standard way of describing that value. And let’s say there a few of these inconsistencies… I’m going to give up and hack on something else, sadly!
- -So in advance, it’s worth cleaning up the data, making sure things are consistent and explained.
- -At some point the conversation about who owns what, as the result of a hack day, will come up. Some of the work that hack day organisers can do in advance is to discuss the kinds of rights agreements that might be made, from the point of view of the organisations and their ownership of data and derivative works; from the point of view of the hacker and the ownership of and copyright over the code they write and any improvements they might make to the data; from the point of view of the organisers and any general principles they put in place in advance of the event (everything will be open sourced under a creative commons licence, for instance), and also from the position of whoever the hack might be for - the users.
- -There are a few thorny issues here, so I shall cover this some more in another post.
- -I find it interesting that hack days have matured to the point where we are now looking at how to ensure that participants on both sides get the most from the day. What’s more, I saw definite improvements in the quality of the data that came through at the latest Culture Hack, and indeed that seems to be happening at other hack days too.
- -Planning for the hack, or setting things up so that good things come from a unique combination of talents is a smart idea. I’m looking forward to learning about other things that people are doing to ensure hack days go smoothly.
diff --git a/blog/_site/2012/08/16/after-the-hack/index.html b/blog/_site/2012/08/16/after-the-hack/index.html deleted file mode 100644 index fe79c1c..0000000 --- a/blog/_site/2012/08/16/after-the-hack/index.html +++ /dev/null @@ -1,20 +0,0 @@ -A question I was asked today, and it got me thinking. Attend a good hack day and you will see tens of hacks presented in the final rounding-up session, but how many of these prototypes and sketches go on to be developed further, turned into real products and services, companies even?
- -Does it matter if the answer is “well, pretty much none of them!”?
- -Anecdotally I’d say that the vast majority of hacks produced at hack days tend to fall by the wayside and do not receive any further development after the day. However, there do seem to be a small proportion that are taken forward, gain investment (in the broad sense of eye word) and end up as extra features of an existing product, or products and services in their own right.
- -I’ve noticed recently, that whereas many hackdays and latterly hackathons started out as days for experimentation and exploration we are now seeing them being used as a way for companies to find and acquire talent, and one of the things put to potential attendees is the idea that if they’re lucky, and their hack is “good enough” then they will get a chance to present their idea to a handful of influential and powerful investors/industry people. Perhaps with a suggestion that their hack could get some seed funding to turn it from a hack into an investable proposition, gain some additional funds to turn it into a prototype, or just straight up get the attention of these important people in order to get a first/better job.
- -I think that this is probably a strong motivator for young hackers and designers - to get the “break” they’ve always been hoping for, and that’s an admirable thing to hope to achieve for your attendees as a hack day organiser.
- -However, putting some kind of promise of a “prize” at the core of the event, I feel, alters it and turns it away from a playful, fun, collaborative event into one that is much more serious, competitive and siloed. I know the feeling from first hand experiences, having attended non-competitive hack days versus as well as ones that have an element of competition.
- -I’m quite competitive, so even if the prize is basically my day rate for two days’ work, I’d be pretty motivated to make sure I ‘win’ (whatever that means!). The trouble is, that in doing so you end up closing down and not collaborating helpfully with those around you, as much as you might have done had the competition element not been part of the mix.
- -For that reason, I’m not a big fan of “big prize” hack days, where teams of people who already work together go to an event to show how wonderful they are against all the other company teams. Gone is the element of playful collaboration, learning and exploration that I find so exciting about hack days.
- -I guess that’s why I find the term “hackathon” irritating - I have a (probably incorrect) mental connection between “hackathon” and “competitive hacking event” versus “hackday” and “collaborative hacking event”.
diff --git a/blog/_site/index.html b/blog/_site/index.html deleted file mode 100644 index 6ea39ad..0000000 --- a/blog/_site/index.html +++ /dev/null @@ -1,144 +0,0 @@ -16 Aug 2012
- -15 Aug 2012
- -14 Aug 2012
- -Draft
- -24 Jul 2012
- -24 Jul 2012
- -19 Jul 2012
- -05 Jul 2012
- -Draft
- -Draft
- -27 Jun 2012
- -04 Jun 2012
- -Draft
- -29 May 2012
- -26 May 2012
- -Draft
- {% else %} -{{ post.date | date_to_string }}
- {% endif %} -