Sketching with Code

Loosely-coupled productivity

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’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.