McFilter

Spreading the DoES Liverpool Ethos

I don't have a good name for the approach I'm hoping to explain in this blog post, which is increasingly annoying as more and more I want to refer to it.

It has elements of the hacker ethos, but that term is so overloaded and abused these days. Some of it is algorithmic thinking, or Internet/networked thinking, but that misses the maker tools in the practitioner's toolbox. There are elements of design thinking in there too.

When I was planning to talk about it at Laptops and Looms II (this is as close as I'll get, I think, to writing this bit up) I used the term "Digital by default" everywhere but the more I think about it, the more that feels like a mis-appropriation of that term.

There's more in that sketch than I'm getting to today. Hopefully I'll expand on that soon. There is at least a half-written blog post to cover a chunk of it.

The nearest I've got to a catch-all term for it, is the DoES Liverpool ethos - because that's where I see it most strongly. But some of that is because that's also where I hang out with like-minded people with this approach the most.

Hopefully some examples will help clarify things.

A couple of days before I started writing this, Stuart Ian Burns sent these tweets.

Sorry, should have mentioned they're films. Before you ask I have no idea how APIs work or what to do with them.

— Stuart Ian Burns (@feelinglistless) January 2, 2015

He's actually quite far along the road of working out how he could use computers to solve the problem he's got. But unfortunately, not far enough along to actually get the answer. He knows some of the language, but still can't achieve the result. For someone with even a reasonably limited level of coding, it's not a hard task, but it's not something you'd ever hire an agency to build for you.

We have it all over the place at DoES - small tools which bring the power of bigger, existing systems to bear on solving problems and helping to automate and smooth operations.

The script that trawls Twitter, IRC and our Google calendar to gather the weeknotes, and then creates a blog post on Wordpress for them, and emails the organisers to remind them to check it over and publish it. The simple use of a hashtag gives us a multi-user authoring system for contributions, without the overhead of building our own user database or a UI for submitting contributions. Likewise, Google calendar gives us a cross-platform, desktop and mobile calendaring system

Or the script John wrote to automate the process of filling in our availability for the week so we make sure someone is around to open up and close up. It uses the same Google calendar to know when our opening hours are extended by an evening meetup or weekend event, and creates a Doodle poll to provide the UI for people to populate which sessions they can cover. Doodle isn't designed to solve that problem - it wants you to narrow down on a small subset of possible days/times, rather than spreading participants across all of the options, but it suits our needs. Then there's the enhancement script to that, which checks each day and emails reminders if there's still a gap.

I expect that no more than a few days work has gone into building all of that, and it's been spread across a number of months as the needs arose. It's the sort of solution you get when you're aiming for maximum automation for minimum effort, with an eye to integrating into the systems that people have already built to solve parts of the problem.

It's really difficult for an agency to solve the problem in that way, and as a result I'd be surprised if it came in as less than a few weeks of work, and quite possibly a few months. It would take them too long to gain the deep knowledge of the workings of the organisation to be able to propose the integration with the existing tools, and they'd tend towards minimising work for themselves (naturally) by reusing tried-and-tested content-management systems with their one-size-fits-all user logins and content creation.

It isn't just in the software realm. Our Doorbot door-entry system requires plenty of software to enable our RFID-card access control - and has been enhanced to log hot-desk usage in our accounts system, and further enhanced to play personalised theme tunes upon arrival (or pirate- or halloween-themed alternatives on Talk Like a Pirate Day and Halloween) - but is also leverages Raspberry Pi computers and electronics, coupled with laser-cutting for the RFID reader enclosure. Not to mention how it piggy-backs on the existing RFID infrastructure to allow people to use their Oystercard or touch-n-pay credit card as their access card if they want to.

It's the way that the organisation has an internalised sense of the malleability of the world that software and digital fabrication brings.

And once you bring electronics and digital fabrication into the mix the number of firms you could hire drops to a vanishingly small number (at least for the next few years).

It also includes a culture of sharing. If you design a 3d-printed attachment for your Dyson, you post the files online for others to use, adapt and share. You might not publish all of the parts, if keeping it secret gives you a competitive advantage, but if not then you contribute it to the commons as you know someone else might find it useful to rework for their situation, and understand that next week you might be using their cooker knob design as the basis for a control panel.

Adopting this culture of embedded software and making know-how would give a company an advantage over any of its competitors who haven't yet realised how the world is changing. In the short-term it will help smooth their processes and increase productivity; and in the long-term make them more likely to spot new possibilities enabled by software letting them communicate better with their customers; or more easily reconfigure their production workflow; or creating entirely new services and products.

Working out how we encourage more of our existing companies to do that will let the city, or the country, thrive. The Silicon Valley approach would be for a new startup to "disrupt" the incumbent, with little regard for any of the people involved in that incumbent. What if we found a way to help the incumbents (particularly the smaller ones) embrace the new possibilities? Would that let us transition to a better future with a lower human cost?