Workshops and Talks

It's XP, Stupid!

Given at Swindon Agile Practicioners on 27th June, then Agile On The Beach on 13th July 2018

We’re all doing Agile nowadays, aren’t we? We’ll all delivering software in an Agile way. But what does that mean? Does it mean sprints and stand-ups? Kanban even? But what about Extreme Programming? If as a development team we’re not using pair programming, test driven development, continuous integration, and other XP practices, then we’re not really doing Agile software development and we may be on a march to frustration, or even failure.

Full details, photos and video at Agile on the Beach web site

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.

• Download PDF of slides
• View slides online (Slideshare)

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 September

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 to legacy?

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 legacy code.

• Photos from Agile on the Beach 2017
• Slides from presentation (Slideshare)

Lean Coffee

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 necessary.
• 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.

Retrospective

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.

Download PDF

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 2016-11-02

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

Download PDF

Becoming a better programmer: writing Clean CodeCOBOL

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

Download PDF

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 caused 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 cyber-panopticon?

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.

Download PDF

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