Workshops and Talks
Here I pin a selection of PDF and original files from various workshops, talks, and lightning talks that I've done
over the years. If you'd like me to come and do any of these, or something different, at your MeetUp or other get
together, please get in touch.
All the slides are licensed under the Creative Commons
Attribution-NonCommercial-ShareAlike 4.0 International License.
BarnCamp/HacktionLab: A Lean Burn-Out Retrospective
Given at Tech Tactics for Social Change on 22nd October 2017
How did I get here? How did HacktionLab get here, and why? What is BarnCamp? What is Lean? How Lean has HacktionLab been? What are some of my favourite books? Where can an old tech activist go to lie down and get some peace?
All these questions, and possibly a couple more, were answered in this talk I get at Tech Tactics for Social Change.
How I Learned to Stop Worrying and Love Legacy Code
Given at Swindon Agile Practicioners on 28th June, Agile On The Beach on 6th July, and Elsevier on 12th
Legacy Code. I never wrote it; everybody else did! How many times have you waded through an ageing, decaying,
tangled forrest of code and wished it would just die? How many times have you heard someone say that what really
needs to happen is a complete rewrite? I have heard this many times, and, have uttered that fatal sentence
myself. But shouldn’t we love our legacy code? Doesn’t it represent our investment and the hard work of
ourselves and our predecessors?
Throwing it away is dangerous, because, before we do, we’ll need to work out exactly what it does, and we’ll need
to tweeze out that critical business logic nestled in a deeply entangled knot of IF statements. It could take us
years to do, and we’ll have to maintain two systems whilst we do it, inevitably adding new features to them
both. Yes we get to reimplement using the latest, coolest programming language, instead of an old behemoth, but
how long will our new cool language be around, and who will maintain that code, when it itself inevitably turns
We can throw our arms in the air, complaining and grumbling about how we didn’t write the code, how we would
never have written it the way it is, how those that wrote it were lesser programmers, possibly lesser humans
themselves, but the code still remains, staring us in the face and hanging around for longer that we could
possibly imagine. We can sort it out, we can improve it, we can make it testable, and we can learn to love our
2017-02-01 and then practical session 2017-03-01, Oxford Drupal Users Group
Lean Coffee was started in 2009 in Seattle by Jim Benson and Jeremy
Lightsmith. It is a format for having an agenda-less meeting, but not those usual disorganised meetings without
agendas which go on for hours and leaves you banging your head against the table, but rather one with a strict
set of guidelines to ensure that what is talked about is what everyone wants to talk about, that nobody talks
for too long, and that when the majority are finished discussing a topic, the group moves on.
The basic structure is:
- You need enough pens (felt-tip are good) for everyone, a pack of index cards (or post-its), some post-its,
something with a count-down timer on it, and some sticky dots (optional).
- Get into groups of up to eight. So if there's twelve people, split into two groups of six.
- Write up three of the index cards with the titles BACKLOG, WIP, and DONE; place these on the table in the
middle of the group as the headings of three columns.
- Pass around some index cards and a pen to each of the participants.
- The participants write topics they'd like to talk about on the index cards; give everyone say five minutes
to do this.
- Each particpant then reads out whats on their cards in turn, with a short since sentence explanation, if
- The cards are then laid out on the table in front of everybody, dots are distributed, and people have two
minutes to vote on which ones they would like to talk about. Lean Coffee suggest two dots per person, but I
prefer to use three each.
- Once voting has taken place, order the cards with dots on in a pile with the cards with the most dots at the
top and place this pile into the backlog. Discard the cards with no dots.
- The meeting then starts with the first card on the pile being moved to the WIP column. The timer starts
(this should be two or three minutes maximum) and so does the discussion. At the end of the time period,
whoever is talking finishes their sentence and the particpants vote on whether to continue.
- Voting is done by putting a thumbs up (I'd like to continue talking about this), thumb level (I don't mind
if we continue or stop), and thumb down (I don't want to talk about this any longer).
- If the majority is thumbs up, the timer starts again and the group carrys on talking. If the majority is
thumbs down, or level thumbs, then the group stops talking about it. If there's an equal number of thumbs up
and thumbs down, then the thumbs up carry it; you could however decide to do this differently.
- When a topic is finished, then it is moved to the DONE column, the next one is moved from BACKLOG to WIP,
and the timer is started again.
- This continues until all the cards have been discussed, or the meeting runs out of time.
Once the meeting is finished, it's a good idea to have a restrospective, especially when it's the first time with
a group, to see what everyone liked or didn't like about it. You can use a white board, the post-its and the
pens for this.
Pair Programming and Mob Programming
2017-01-04 Oxford Drupal Users Group
I've been interested in Mob Programming ever since I saw Woody Zull give a talk about it at 2015's Agile On The
Beach conference - (see video). We tried it when I was working at PWG, and then again at Loop, and there were a
number of interesting outcomes.
Pair Programming is where two people work together on a problem, sharing screen and keyboard. Mob Programming is
where a whole team works together on a problem. This short talk introduces both of them, shows how they work,
and covers my experiences in using them in real-world situations.
Keep it Simple: An Ode to the Minimum Viable Product
2016-09-29 - first given at Swindon Agile Practitioners Meet-up, subsequently at Oxford Drupal Users Group
Lean software methodology tells us about the Minimum Viable Product; the smallest and simplest work that we can
do to prove an idea and gain feedback and insight. Applied to software, this could be the least amount of code
you could write to deliver something that the customer wants; an ideal little skateboard that’ll get them to
work on time.
But is your solution the simplest that it could be? Could it be that your customer doesn’t even require some
software, or even computer, in order to achieve what they want? With anecdotes from the real-world, this talk
looks a the pitfalls of determining what the customer really needs, rather than what they want, and reminds us
technologists that, horror of horrors, perhaps they don’t need a single line of code or a single new cloud
server to do what they need. Remember that a pencil is a technology and just the tool for the job in many
Becoming a better programmer: writing Clean
Yet to be given
You're a programmer, right? Well, stop being a hacker, have some respect, and craft your code. And don't blame
your tools either,
even a language as ancient as COBOL can be written cleanly...
COBOL - An Introduction
2015-12-06 - first given at HacktionLab Hebden Bridge, subsequently at Oxford Drupal Users Group
It's old, very old in computer programming terms. It's always been frowned on by real computer scientists and it
all that terrible spaghetti code that plagued us back in the 60s, 70s, 80s, and even today. But what is COBOL?
Is it really that
bad? And do people still use it? Let's learn some COBOL and find out!
Download PDF and Download
and hack code
Prism and the Darkside of the Net
2015-06-08 - first given at Shambala Festival 2014, subsequently at BarnCamp 2015
Edward Snowdon's revelations rocked the world. But what is it all about? Who's watching and what is the
Download PDF and Watch Video
Linux/Unix Networking Introduction
2015-01-15 - first given at Bristol Wireless in 2010, subsequently to staff at PWG
A look at how the TCP/IP stack works using the OSI model as a way of describing it. How to manage networks under
Unix and Linux,
and how to approach diagnosing issues, and resolve them.
The HTML5 <canvas> as seen through a fractal eye
2011-06-11 - first given at BarnCamp 2011
What can you do with the new canvas element and how much chaos can you cause?
Download PDF and Download and hack code
work is licensed under a Creative Commons
Attribution-NonCommercial-ShareAlike 4.0 International License.