Workshops & 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.
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.
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.
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 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.
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
06/12/15 - 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
08/06/2015 - 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
January 2015 - 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
11/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
(c) 2017 Mike Harris & Broad Bean Productions Ltd. Copyleft where specified.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.