Last updated: January 24, 2020 05:22 AM (All times are UTC.)

January 23, 2020

I’ve been using Goodreads to track the books I’ve read since 2014. Since then, I’ve read on average 18.3 books per year.

I don’t have a reliable way to track how much time I spend reading, but anecdotally it’s around 20 minutes per day. I read in dribs and drabs. On one day I’ll read for hour and then I won’t read a thing for days on end.

Assuming I live to the age of 80 and that I’ll be reading until the day I die, that gives me 47 book-reading-years left.

At my current rate of reading, I have 860 books left to read in my life time.

If I was to increase my reading time to 30 minutes per day, that’ll mean I’ll be getting through 27.5 books per year. That now means I could get through an additional 432 books, a total of 1292 books in my remaining years.

Now, let’s push this further and say I read for an hour a day. It may sound like a lot, but most of us watch far more TV than that in any given day. A few small habit changes and it’s possible to read more.

Reading for an hour daily means I’ll be getting through 55 books in a year. At this rate I could get through 2858 books before the age of 80, 1725 more just from increasing the time I read from 20 to 60 minutes per day.

That’s why I’m going to push myself to read for at least an hour every day.

January 21, 2020

An old Mac Mini server was ‘going in the skip’ because it had been replaced as an office server. It was handed to me instead, due to my reputation as an IT dumpster diver. (server model: 2.66 GHz Core 2 Duo (P8800))

I did MANY upgrades to get it to the latest release, 10.13 High Sierra. A couple of weeks later, Apple announced that they were stopping further updates. I understood at the time this was because this generation of hardware had a 32-bit EFI boot system, despite being a 64-bit processor and that it was only possible to boot Ubuntu by modifying the Ubuntu OSI image. This may have been true at the time. I’ve tried to get to know MacOS but it sometimes feels really sluggish on this hardware and now I’m not seeing the latest features, I decided to consider giving up the struggle.

Today, I tried to boot an Ubuntu 64-bit image from a ‘live’ USB memory stick I’d built on another Ubuntu system. I wanted to see how it would fail. To my surprise, it booted. I had to go into Settings to add a WiFi connections. The only problem I had was that tinny sound came from the Mac Mini’s internal speaker. When I plugged the headphone socket to the TV, rather than being routed by HDMI and the TV’s stereo sound inputs as Mac OS would do, I had no sound. A full install might fix that.

You get (this) Mac to boot from another device by pressing the <Alt> key at startup.
(This didn’t work on a white iMac with a Core 2 Duo processor when I tried months ago but that was probably an earlier version of Ubuntu.)

January 19, 2020

Number word sequences by Stuart Langridge (@sil)

I was idly musing about number sequences, and the Lychrel algorithm. If you don’t know about this, there’s a good Numberphile video on it: basically, take any number, reverse it, add the two, and if you get a palindrome stop, and if you don’t, keep doing it. So start with, say, 57, reverse to get 75, add them to get 57+75=132, which isn’t a palindrome, so do it again; reverse 132 to get 231, add to get 132+231=363, and that’s a palindrome, so stop. There are a bunch of interesting questions that can be asked about this process (which James Grime goes into in the video), among which are: does this always terminate? What’s the longest chain before termination? And so on. 196 famously hasn’t terminated so far and it’s been tried for several billion iterations.

Anyway, I was thinking about another such iterative process. Take a number, express it in words, then add up the values of all the letters in the words, and do it again. So 1 becomes ONE, and ONE is 15, 14, 5 (O is the fifteenth letter of the alphabet, N the fourteenth, and so on), so we add 15+14+5 to get 34, which becomes THIRTY FOUR, and so on. (We skip spaces and dashes; just the letters.)

Take a complete example: let’s start with 4.

  • 4 -> FOUR -> 6+15+21+18 = 60
  • 60 -> SIXTY -> 19+9+24+20+25 = 97
  • 97 -> NINETY-SEVEN -> 14+9+14+5+20+25+19+5+22+5+14 = 152
  • 152 -> ONE HUNDRED AND FIFTY-TWO -> 15+14+5+8+21+14+4+18+5+4+1+14+4+6+9+6+20+25+20+23+15 = 251
  • 251 -> TWO HUNDRED AND FIFTY-ONE -> 20+23+15+8+21+14+4+18+5+4+1+14+4+6+9+6+20+25+15+14+5 = 251

and 251 is a fixed point: it becomes itself. So we stop there, because we’re now in an infinite loop.

A graph of this iterative process, starting at 4

Do all numbers eventually go into a loop? Do all numbers go into the same loop — that is, do they all end up at 251?

It’s hard to tell. (Well, it’s hard to tell for me. Some of you may see some easy way to prove this, in which case do let me know.) Me being me, I wrote a little Python programme to test this out (helped immeasurably by the Python 3 num2words library). As I discovered before, if you’re trying to pick out patterns in a big graph of numbers which all link to one another, it’s a lot easier to have graphviz draw you pretty pictures, so that’s what I did.

I’ve run numbers up to 5000 or so (after that I got a bit bored waiting for answers; it’s not recreational mathematics if I have to wait around, it’s a job for which I’m not getting paid). And it looks like numbers settle out into a tiny island which ends up at 251, a little island which ends up at 285, and a massive island which ends up at 259, all of which become themselves1. (You can see an image of the first 500 numbers and how they end up; extending that up to 5000 just makes the islands larger, it doesn’t create new islands… and the diagrams either get rather unwieldy or they get really big and they’re hard to display.2)

A graph of the first 500 numbers and their connections

I have a theory that (a) yes all numbers end up in a fixed point and (b) there probably aren’t any more fixed points. Warning: dubious mathematical assertions lie ahead.

There can’t be that many numbers that encode to themselves. This is both because I’ve run it up to 5000 and there aren’t, and because it just seems kinda unlikely and coincidental. So, we assume that the fixed points we have are most or all of the fixed points available. Now, every number has to end up somewhere; the process can’t just keep going forever. So, if you keep generating numbers, you’re pretty likely at some point to hit a number you’ve already hit, which ends up at one of the fixed points. And finally, the numbers-to-words process doesn’t grow as fast as actual numbers do. Once you’ve got over a certain limit, you’ll pretty much always end up generating a number smaller than oneself in the next iteration. The reason I think this is that adding more to numbers doesn’t make their word lengths all that much longer. Take, for example, the longest number (in words) up to 100,000, which is (among others) 73,373, or seventy-three thousand, three hundred and seventy-three. This is 47 characters long. Even if they were all Z, which they aren’t, it’d generate 47×26=1222, which is way less than 73,373. And adding lots more doesn’t help much: if we add a million to that number, we put one million on the front of it, which is only another 10 characters, or a maximum added value of 260. There’s no actual ceiling — numbers in words still grow without limit as the number itself grows — but it doesn’t grow anywhere near as fast as the number itself does. So the numbers generally get smaller as they iterate, until they get down below four hundred or so… and all of those numbers terminate in one of the three fixed points already outlined. So I think that all numbers will terminate thus.

The obvious flaw with this argument is that it ought to apply to the reverse-and-add process above too and it doesn’t for 196 (and some others). So it’s possible that my approach will also make a Lychrel-ish number that may not terminate, but I don’t think it will; the argument above seems compelling.

You might be thinking: bloody English imperialist! What about les nombres, eh? Or die Zahlen? Did you check those? Mais oui, I checked (nice one num2words for supporting a zillion languages!) Same thing. There are different fixed points (French has one big island until 177, a very small island to 232, a 258, 436 pair, and 222 which encodes to itself and nothing else encodes to it, for example.Not quite: see the update at the end. Nothing changes about the maths, though. Images of French and German are available, and you can of course use the Python 3 script to make your own; run it as python3 no for Norwegian, etc.) You may also be thinking “what about American English, eh? 101 is ONE HUNDRED ONE, not ONE HUNDRED AND ONE.” I have not tested this, partially because I think the above argument should still hold for it, partially because num2words doesn’t support it, and partially because that’s what you get for throwing a bunch of perfectly good tea into the ocean, but I don’t think it’d be hard to verify if someone wants to try it.

No earth-shattering revelations here, not that it matters anyway because I’m 43 and you can only win a Fields Medal if you’re under forty, but this was a fun little diversion.

Update: Minirop pointed out on Twitter that my code wasn’t correctly highlighting the “end” of a chain, which indeed it was not. I’ve poked the code, and the diagrams, to do this better; it’s apparent that both French and German have most numbers end up in a fairy large loop, rather than at one specific number. I don’t think this alters my argument for why this is likely to happen for all numbers (because a loop of numbers which all encode to one another is about as rare as a single number which encodes to itself, I’d guess), but maybe I haven’t thought about it enough!

  1. Well, 285 is part of a 285, 267, 313, 248, 284, 285 loop.
  2. This is also why the graphs use neato, which is much less pleasing a layout for this than the “tree”-style layout of dot, because the dot images end up being 32,767 pixels across and all is a disaster.

In someone else’s project (which they’ll doubtless tell you about themselves when it’s done) I needed a tiny Python templating engine. That is: I wanted to be able to say, here is a template string, please substitute a bunch of variables into it. Now, Python already does this, in about thirty different ways, and str.format or string.Template do most of it as built-in.

str.format works like this:

"My name is {name} and I am {age} years old".format(name="Stuart", age=43)

and string.Template like this:

    "My name is $name and I am $age years old"
    ).safe_substitute(name="Stuart", age=43)

Both of which are pretty OK.

However, what they’re missing is loops; having more than one of a thing in your template, and looping over a list, substituting it each time. Every even fractionally-more-featureful templating system has this, whether Mustache or Jinja or whatever, of course, but I didn’t want another dependency. All I needed was str.format but with loops. So, I thought, I’ll write one, in about four lines of code, so I can just drop the function in to my Python file and then I’m good.

def LoopTemplate(s, ctx):
    def loophandler(m):
        md = m.groupdict()
        return "".join([LoopTemplate(md["content"], val)
                        for val in ctx[md["var"]]])
    return re.sub(r"\{loop (?P<var>[^}]+)\}(?P<content>.*?)\{endloop\}",
                  loophandler, s, flags=re.DOTALL).format(**ctx)

And lo, twas so. So I can now do

    "I am {name} and my imps' names are: {loop imps}{name}{endloop}",
        "name": "Stuart",
        "imps": [
            {"name": "Pyweazle"}, {"name": "Grimthacket"}, {"name": "Hardebon"}

and it all works. Not revolutionary, of course, but I was mildly pleased with myself.

Much internal debate about whether loophandler() should have been a lambda, but I eventually decided it was more confusing that way, on the grounds that it was confusing me and I knew what it was meant to be doing.

A brief explanation: re.sub lets you pass a function as the thing to replace with, rather than just a string. So we find all examples of {loop something}...{endloop} in the passed string, look up something in the “context”, or the dict of substitution variables you passed to LoopTemplate, and then we call LoopTemplate again, once per item in something (which is expected to be a list), and pass it the ... as its string and the next item in something as its context. So it all works. Of course, there’s no error handling or anything — if something isn’t present in the context, or if it’s not a list, or if you stray in any other way from the path of righteousness, it’ll incomprehensibly blow up. So don’t do that.

January 16, 2020

New Starter: Sam Harper-Wallis

Here at Made, we are always on the look-out for talented and passionate people who can help us on our mission to provide clients with a first-class service. 

Over the past few months, we have been lucky enough to find a few such individuals, so over the coming posts, we wanted to introduce you to them officially,  whilst also welcoming them into the Made family.

We asked our new starters to answer a few questions to try and learn a little more about them and we thought we would share their answers with you. 

First up…

What is your name?
Sam George (only if I am naughty) Harper-Wallis

And where are you from?

Digital Project Manager

What is it you do?
In a sentence…
I facilitate the delivery of the scope of a project for Made Media’s clients.

In a paragraph…
My job as a project manager involves many different functions: cat herder, scope wrangler, delivery man. As a PM it’s my job to watch over and coordinate projects to make sure that we can give the client exactly what they need on time and budget. Day to day this includes project client calls, trello management, testing, SoW writing, sprint briefing, requirement defining, and dependency gathering.

Tell us a little about your professional journey to Made?
In 2010 I went to university in Manchester to study Cellular Molecular Biology. I always had a passion for science, especially biology, so it was an easy choice.

After completing university I started to look for a job so naturally as a newly minted science graduate the obvious choice was to become a recruitment consultant. I did this job for around 6ish months, before being moved into a contracts manager/business manager role to scout out for new business opportunities.

I then fell into a product owner role with a new business being spun out from my company, focusing on supply teachers for the education sector. While working as a product owner, I was also dipping into project management. I really enjoyed this side of the business, so I decided to look for a job with an agency which my mentor at the time suggested would be the best challenge for me.

I moved to a small bespoke agency in Manchester, but I knew I wanted to move back home, so in May 2018 I decided to take an opportunity in Birmingham as a Digital Project Manager, with another agency based in the Jewellery Quarter. During my first year, I worked with some massive clients and really honed my project management skills.

Through this project management work, I started to work with the operations director who helped me implement changes which improved company-wide cohesion. I was then offered a new role that sat between the account and studio team. Here I was the gatekeeper for all things process. The studio process, work request process, support and SLA process. During this time I implemented new processes to improve efficiency. I did this for over half a year but my heart was elsewhere. I wanted to get back in front of clients and deliver great projects which I can be proud of.

In October I had an interview here at Made. We take a really pragmatic approach to development resource and project management which appealed to me. So I was extremely pleased when I was offered the job as a project manager.

I joined in November and so far I am loving every day! 

What do you like doing when you’re not working?
Mostly cooking, gardening, eating, walking the doggo.

What is your proudest achievement?
I completed Bravo Training in the Army Reserves. I started my 16 days of training at Grantham, getting up at 5 am and going to bed, at some times 11 pm.  This wasn’t the hard part, nor the constant exercise or sleeping in the cold or even drills. It was being away from my girlfriend Hannah.

What is your slogan in life?
You can’t control people’s actions but you can control your reactions to them.

What is the best thing you’ve ever seen performed?
Cirque du Soleil.

‘Alexa…’ or 'Hey Google…’?
Hey Google…

If you were an Animated Character, who would you be and why?
My girlfriend helped me answer this as I was struggling - “You’re Jimmy Neutron - You have a massive head, not because you’re clever, you just have a massive head”.

What would the title of your autobiography be?
The man with a massive head.

What is the best thing you’ve MADE for someone or have had MADE for you?
I make the best lasagne - FACT.

January 15, 2020

I loved reading Patrick Collison’s Fast Project. He has compiled a list of ambitious projects that were completed incredibly quickly. Some of my favourite examples include the iPod shipping in 290 days after being started and Amazon Prime being brought to life in 6 weeks.

January 13, 2020

After a few weeks off over the holiday period, I’ve been using The Theme System Journal to help get my habits back on track.

These are the daily habits I’m currently tracking:

  1. Reading (20 mins+)
  2. Writing (20 mins+)
  3. Complete highlight
  4. Deep work (3 hours+)
  5. Meditate
  6. Close activity rings
  7. Go for a walk
  8. No alcohol
  9. Finish work at 5:30pm

January 10, 2020

Reading List 246 by Bruce Lawson (@brucel)

Happy Nude Year, you perfectly pouting porcupine!

January 09, 2020

Last year, I started my review with this:

One of the wonderful benefits of these annual reviews is that it encourages you to look back at the year as a whole. I was reminded that 2018 was actually a really good year.

It’s true: these reviews are a great way to reflect on the year and they help remind you how much you’ve accomplished. I nearly didn’t write a review this year. 2019 was a mixed bag and it didn’t feel like there was much to share. But as this is my fifth annual review (see 2015, 2016, 2017, 2018), I knew I’d regret it if I didn’t publish this.

So, with that said, here was my 2019.

What went well

Completed the house extension. Boy does it feel good to write those words! We started planning the house extension in late 2017 and it has taken up a good amount of our time and energy since then. We’ve added an additional bedroom, doubled the size of an existing bedroom, increased the size of our bathroom, and added a utility room and a garage. It was stressful at times – it often felt like a new problem would present itself daily – but my wife and I worked through each issue together and that has made us closer. It’s the biggest thing we’ve worked on and accomplished together.

Home office improvements. As part of the house extension, my home office got an upgrade. My old office was in a small bedroom which wasn’t even big enough to fit a double bed. The new office is much more spacious. I’ve added additional storage and my favourite new addition: a reading chair. It’s great being able to move from my desk and sit in comfort with my iPad to plan the day, read or just think. I’m looking forward to improving the office further in the coming year.

My current desk setup
My favourite new additional to the office: a reading chair

5 years of self-employment. November marked my 5th anniversary of self-employment. It can’t believe it has been that long. This year has been kind to my business – I’m on track to have my best financial year yet and have signed up new clients that I’m excited to work with. I’m still transitioning from freelancer to consultant, and that has been both challenging and rewarding.

Health & diet. My wife and I switched to a pescatarian diet in November 2017. Throughout the past year, we’ve gradually eaten less fish and dairy and most of the meals we eat are vegan. I’m not sure we’ll ever go completely vegan, but my energy levels have improved and my weight has stabilised from eating a mostly plant-based diet. The Apple Watch continues to play a big role in keeping me active. I try to close my activity rings most days and in November I got my first Perfect Month badge. I’ve also been using Pedometer++ for step counting and managed to complete 10 out of 12 monthly challenges.

Reading. While I only read 16 books in the past year, the amount of books I read outside my usual comfort zone was higher (mostly thanks to the book club I participate in). Books like The Lessons of History, Educated and A Million Miles in a Thousand Years are not books I would have picked to read, but I learnt a lot from them and enjoyed them greatly.

A few other things that I’ve enjoyed or accomplished in 2019

  • I jumped out of a plane for the first time and I can’t wait to do it again. The adrenaline rush is like nothing else I’ve experienced.
  • I started meditating regularly again using the Waking Up app (the 50 day introductory course is incredible, I couldn’t recommend it more highly).
  • I started using the Theme System Journal to track my habits and keep focused during the day (I’ll be writing about this soon).
  • I’ve continued cutting down on my social media usage after deleting my Facebook account in 2018. I’ve only tweeted a handful of times and I finally deleted Instagram in November. It feels great.
  • I went to watch the Allam British Open Squash Championships in Hull. One of the games we saw just so happened to be the game of the season.
  • We had our first vegetarian tasting menu at Carters of Moseley to celebrate our wedding anniversary. It was superb.
  • I upgraded to the iPhone 11 Pro. I’m so pleased with both the camera and battery performance. I’m taking more photos as a result.
  • I travelled to Amsterdam to work with the guys at modmore. It’s a beautiful city and I can’t wait to return so I can explore more of it.
  • We also travelled to Barcelona to celebrate New Years with our good friends Stu and Chloe. The inside of the Sagrada Família was a highlight.
  • And a shout out to my mastermind group for their help and support. It has been amazing to watch and learn from them.

What went badly

Overworking. The house extension was tough. We spent much of our spare time in the first half of the year painting and decorating. As the house extension was nearing completion, I promised myself I’d dedicate all of my energy to my business once it was done. And I did that, but at a cost. I spent too many days and weekends working long hours. It wasn’t all that bad: I rebuilt my emergency savings fund and produced a lot of good work. But it’s not something I want to continue. Getting my work/life balance right is going to be a primary focus for 2020.

Over consumption. Despite cutting back on social media, I still felt I over consumed on media this year… news, politics and too many podcasts. I’m a podcast junky: I fill every spare moment with sound from my AirPods. I can’t remember the last time I took a walk without headphones in. I recognise that I need to change, so 2020 is the year that I allow more silence into my life.

Writing habit. This one is simple: I didn’t prioritise or make time for writing this year. I have started redesigning my blog ready for more writing and publishing. Of all my goals for the coming year, I want “writing” to be in my “what went well” section of my 2020 review.

Relationships. It’s hard to share this one as it’s so personal, but I’ve not invested enough time or effort in my family and friendships this year. Nor have I invested enough in my own marriage. I was distracted by other things, when really relationships are the most important thing I have. I know I can do better.

How I did against my 2019 goals

Complete the house extension. Done. We’re really happy with how this has gone. Score: A

Systems for my business. I’m in a better place with systems than I was this time last year, but there’s still more to do. Score: C

Reading. I only read 2 fiction books (6 was my target). And while I only read 16 books total, the quality and diversity of books I read this year was better than previous years. Score: C

Writing. Ugh. Score: F

Continue with our pescatarian diet, tweaking and finding new healthy recipes. I only stumbled and eat meat once (when I was stuck in Amsterdam airport for 24 hours due to a cancelled flight). We’ve found a bunch of new recipes we like and I enjoy cooking more than ever. Score: B

Improve the quality of my sleep with a better shutdown ritual in the evening. I never got a shutdown ritual to stick, but I have been tracking my sleep and have been going to bed at a consistent time. Score: C

Close the activity rings daily on my Apple Watch. Pretty good year for this, got my first perfect month and closed my activity rings on more days than not. Score: B

Start my daily meditation practice again. I’m not meditating every day, but in the last few months in particular I have been meditating most days. Score: C

Continue playing squash 2-3 times per week. It has been a great year for my squash playing and I’ve enjoyed it a lot. Score: A

Things I’m thinking about for 2020

Setting a yearly theme. I’m a long-time Cortex listener. A recurring topic on the show is yearly themes. Myke explains:

Instead of resolutions, we set an overall idea of how we would like to approach each year or season. This becomes almost like a guiding principle for our work and/or personal lives for that period.

I’m been thinking about my 2020 theme for a while and I’ve decided it’ll be The Year of Calm. Last year was frantic, my calendar was full and I had little down time. I want to change that. I’ll be sharing more about this soon.

Less contract work. In the past year, I’ve done a reasonable amount of contracting for local web development agencies. I’m in the process of shifting my business to focus more on my own clients and projects.

Blogging on my personal website. At the end of December, I spent a week redesigning this site. The feeling of having a new website makes me excited about writing again.

Build and release a product. I’ve been discussing some ideas with a friend. All that is left is the hard part: building and shipping it.

Fitness and health. I want to kit my garage out with some basic gym equipment, making it easier to do a morning workout. I’m also planning to do more hiking and cycling with the goal of increasing my base level of fitness. I’d like to reach my ideal body weight of 70kg (currently 75kg).

Environmental impact. The climate emergency we’re in is one of my biggest concerns. The recent scenes in Australia are heartbreaking. We’ve been taking small steps over the past few years, such as reducing single-use plastics, but I’d like to take that more seriously.

That’s all from me. Happy new decade!

January 07, 2020

When I started redesigning this website a few weeks ago, I started from a blank slate (an empty WordPress theme directory and a couple of Sass files that I use to start new projects). Since then, I’ve built out most of the core components to get the site looking reasonable.

On the surface, a blog design is simple. You have posts and pages and that’s usually about it. But when you dig deeper, you realise there’s lots of little design decisions that need to be made.

One such design decision is how blog posts are displayed. The previous version of my blog listed posts chronologically, like this:

The previous version of my blog listed blog posts by title

No dates, no content, just a list of blog posts. This approach is fine if each post is a self-contained topic, but it doesn’t feel particularly well suited to a ‘weblog’ where each post can vary in size. Clicking through to a post with two or three lines of text doesn’t feel right.

Now take Manton Reece’s blog as example:

Manton Reece’s blog

Manton’s blog has two types of posts: full articles and microposts. This is the approach I decided I wanted to take. Sometimes I just want to a share a thought or a link and several lines of text is all that is required. This smaller bite-size approach to blogging is called microblogging (incidentally, Manton runs

The design as it stands currently

This is the design I’ve ended up with. Very much inspired by Manton, I now have two types of post: a standard post and a note. I’m still experimenting with the format, but I hope that now that a post can be tweet-sized, it’ll make it easier to get back into the habit of publishing.

January 06, 2020

RUNOFF another copy? by Andy Wootton (@WooTube)

I was telling a story about my first job a couple of days ago. I was an ‘applications programmer’ at Cambridgeshire College of Art and Technology. There was an Argentinian lecturer who knew our systems. He asked if his wife could use the computer centre facilities to write up her research thesis during the Summer holidays. We were casual users of a text processing ‘tagging language’ for documentation. It was called DSR, Digital [Equipment Co.] Standard Runoff, so my colleague John suggested she used that. The ‘typing department’ had some fancy new ‘word processors’ (I think they were Wang) but we didn’t have any authority over them and wouldn’t be able to help her with problems. We also had doubts about whether they had the capacity for a whole thesis.

So it was that John and, in his absence, I provided occasional help to a charming, intelligent Argentinian woman during the outbreak of the Falklands War in 1982, while the British press ramped up the hatred of British idiots against the entire Argentinian nation. She was the first Argentinian I’d ever met and it was the first time I had any indication that fascism could also infect the UK or was personally shamed by the state of our newspapers. I remember us scooping up some hate-filled tabloid front page and dumping it, seconds before our guest arrived.

In later jobs I learned of Unix roff, nroff and troff and came to assume that Runoff was DEC’s version of the Unix tools. Today I discovered that isn’t true. DEC’s Runoff came from the common ancestor of the Unix tools, Runoff on CTSS then Multics (1964.)
“types out text segments in manuscript form.”

CTSS was also the original home of LISP, ALGOL and the text editor QED, the predecessor of ed, vi and vim.

January 02, 2020

December 24, 2019

For the 2018 festive season I started what I hoped would become a tradition of making Christmas gifts for my friends and family, by making eight wall-mounted bottle openers. I’d had the idea some time in late Autumn 2018, but it was early December before I started, and with everything else I had going on, that didn’t leave much time to do as good a job as I had wanted.

🎵 Last Christmas, I gave you my heart

In my mind I’d imagined elaborate bottle-shaped designs, with either magnets embedded in them or a little box under the opener, to catch the cap, but what I actually produced was less… good.

Amounting to little more than a cheap bottle opener mounted on a piece of pine, with a bit of chalkboard paint complimented with some chalk-based art by Lucy, and a coat of varnish, it’s hardly my best work. They didn’t even have a way of to attach them to the wall. Still, combined with the hampers Lucy and I made for everyone, I don’t think anyone was too disappointed. Except me.

Anyone who isn’t embarrassed of who they were last year probably isn’t learning enough.

Alain de Botton

This year I had a loftier ambition, and with a brand new workshop ready for use and a far longer lead time, I was going to continue the theme of alcoholic beverages by making everyone beer flight paddles.

🍻 Don’t worry, be hoppy

This was inspired by our holiday to Cyprus in May this year, where we partook in Beer Quest, an ale and cider tasting experience hosted by Aphrodite’s Rock Microbrewery. For just £45 you got transport from the hotel, a flight of home brewed beers or ciders, a huge platter of BBQ food, a tour of the brewery, and (most importantly) an open bar, before being transported back to the hotel again.

There’s a reason it’s listed at the top of things to do in Paphos.

Needless to say, there was very little activity from either Lucy or myself for the rest of that day, as we both opted for an early night.

🎅 Believe in your ‘elf

Fast forward four months, to early August, and I’d made some decisions about the paddles:

  • I wanted to use a wood other than pine
  • I wanted to use a finish other than paint or varnish
  • I wanted each paddle to be different

So, armed with little more than some inspiration from Pinterest, I ventured to Homebase and picked up the largest solid oak hobbyboard they did, and a handful of assorted cabinet handles, then popped next door to Homesense and picked up five sets of glasses, ranging in size from shot to pint.

When I got them home, I laid the board on my workbench, and after matching the handles I wanted to use for each set, I sat them on the board and placed them in different positions to find the best arrangement for each set with the most efficient use of the wood available.

Once I was happy with the layout, I used my table saw to chop the board down, then used a pencil and ruler to work out the exact positions of the holes for the glasses.

⛳ Hole in one

Now that I knew where I wanted the holes, I needed to find a way of making the holes. With one exception, none of the paddles were to have holes going all the way though, instead they were to be hollowed down to about half the thickness of the wood, which meant I’d not be able to use a holesaw, but something like a forstner bit should work well.

People don’t want to buy a quarter-inch drill, they want a quarter-inch hole.

Theodore Levitt

And it’s here that my ambition bit off just a little more than I could chew, as each of the glass sets were different sizes, with each requiring a hole larger than any of the forstner bits I already had. I solved this problem by putting my hand in my pocket and spending £55 buying four sets of bits from Amazon, ranging in size from 10mm right up to 90mm in diameter.

I knew that I’d not be able to use any of the larger bits in my hand drill, so had planned on using the drill press at Cheltenham Hackspace, but because the largest forstner bit had a shaft thicker than the chuck at the space could accommodate (oohh-eerrr), Andy from the space very generously let me use his personal drill press, and gave me some tips on how best to get the best results.

So while Lucy did some shopping at the Cheltenham retail parks, I got to work cutting the rest of the holes.

This went mostly OK, but as I started with the smallest holes, and gradually increased the sizes, I didn’t reduce the RPM on the drill as I increased, resulting in a little bit of burning on one of the flights, which I corrected for the next one. I also slipped a couple of times, resulting in some gouges in the wood, but nothing a bit of sanding can’t fix.

I also made the mistake of trying to go all the way though in one direction, thinking a sacrificial board underneath would help prevent tear-out. It didn’t. So for the other three holes needed for that paddle, I drilled a small hole in the centrer of each so I’d know where to start on the other side, then hollowed out half thickness on one side, then flipped it over and hollowed out the other half.

Two hours later, after having cut all the holes, and using the bandsaw to cut the paddle handle, I rescued Lucy from the rain.

💸 Money talks… but all mine ever says is good-bye

Now, I’m very happy being a member of the Cheltenham Hackspace – I’ve met some really nice people there, and in addition to the tools I’ve got access to, the expertise of the other members, and willingness to share it, is second to none.

But Cheltenham is 40 minutes down the M5, which isn’t exactly accessible, and means that when you find a mistake you’ve made after returning home, you can’t exactly just pop back to fix it.

The mistake in this instance was the size of the holes on two of the flights. After some experiments with the placement of the glasses I decided the holes for the skull glasses weren’t deep enough, and that the holes for the wobble glasses needed to not only go all the way through, but also needed to be slightly wider.

Now, despite it still being August at this point, with plenty of opportunity to get back to the space before Christmas to correct these issues, I’m an impatient person, and knew that waiting wasn’t going to scratch the itch I had.

It’s at this point I decided to buy my own pillar drill, and while I was spending money I might as well buy the tools from Aldi I’d had my eye on as well. Fast forward an amount money which was just a tad more than I could really afford, and I was soon the proud own of a bandsaw, belt and disk sander, a paint gun, a nailgun, and of course, a pillar drill.

🙋🏼‍♂️ Professional sawdust maker

With my new tools in tow, increasing the size of the holes was a doddle (and the new sander made it easy to smooth out the curves on the paddle), letting me move onto the next step of rounding over the edges with my router. My router table (also from Aldi, are you noticing a trend here?) is a bit fiddly to set to the correct depth, so it was important to use a piece of scrap wood to test it, but once this was dialled in, I made quick work of it, replacing all the sharp edges with a nice rounded ones.

More tricky was drilling holes for the handles, which needed precision of placement for any with more than a single screw. I also needed to shorten the screws (which were designed to be attached to far thicker things than my 18mm boards), which I did using a Dremel.

The penultimate step was to sand everything. I started with my random orbit sander for the main surfaces of each board, using 180 grit initially before moving to 240 grit. I was able to use a Rotary Flap Wheel Sander (attached to new pillar drill) to sand the inside of any holes which went all the way through, but in inside of any any partial holes needed regular sandpaper and elbow grease.

⚖ Oil be the judge of that

All that remained was to apply the finish, for which I’d opted to use Danish Oil. Applying three coats of oil, wiping off the excess after 5 minutes, and waiting 24 hours between coats, really brought out the natural beauty of the wood. Apparently it isn’t as protective as Lacquer or Varnish, but I think it should be more than suitable for the flights.

Once dried, I attached the handles, placed the glasses, and took these action shots:


In the time between when I originally wrote this post in late August, and Christmas day when it was published, I locked myself in the workshop and decided to put the remaining wood to good use, producing these additional pieces as gifts:

Oh, and I couldn’t go thought all that without at least making one bottle opener that I could be proud of:

I’m really happy with the way these have turned out, and am ever-so lightly jealous that I have to give them away, but happy to do so – I just hope they bring joy to their recipients – and then when I see them next, they’ll offer me a drink of something nice from them.

Happy Christmahanakwanzika!

December 20, 2019

Reading List 245 by Bruce Lawson (@brucel)

Merry Consumerfest, and a Happy Nude Year!

December 19, 2019

Brum tech pub crawl 2019 by Stuart Langridge (@sil)

It’s time for the Birmingham tech pub crawl! Saturday 28th December 2019.

This is called a pub crawl, but it’s really an excuse to get together, hang out, have a couple of drinks — alcoholic or not, that’s entirely up to you and there’s no pressure — in various places around the Jewellery Quarter. (There was discussion of being in the city centre, or in Digbeth, but since it’s a Saturday and we want to talk rather than scream over the music, the JQ it is.) Get away from the turkey and chill out and meet people. Bring your family and your friends along. Pop in for an hour while you’re in town and say hello, or show up at 12 noon and still be there at midnight, it’s up to you. Lots of people come at various points during the day, and it’s all very friendly, so if you don’t think you know anyone, or you’re on your own, that’s not a problem. Come, chat to people, have a drink, have a laugh. The agenda this year is, roughly, six different places and a couple of hours in each, so we move around a bit, but it’s all in the Jewellery Quarter so there’s not a lot of walking. If you’re feeling unsure do feel free to ping me — @sil on Twitter — and I can tell you where we are, and I’ll try to keep things updated during the day.

Everyone is welcome, and everyone is invited. Bring friends along; drink coffees or soft drinks; pop in for an hour; whatever you fancy. Tell everyone about your pressies, talk about all the tech you thought about over the Christmas period, or don’t talk about technology at all and just enjoy hanging out with your mates. Looking forward to seeing you all.

A rough agenda:

  • The Lord Clifden, 12pm - 2pm (they do food if you fancy lunch)
  • The Church, 2pm - 4pm
  • 1000 Trades, 4pm - 6pm
  • The Rose Villa Tavern, 6pm - 8pm (probably grab a bite to eat here if we haven’t already)
  • The Queen’s Arms, 8pm - 10pm
  • The Actress and Bishop, 10pm - whenever

December 17, 2019

One of my goals for next year is to write and publish more often (as it has been for the past few years and I’ve horrifically failed at). But, as everyone knows, before you can start writing you have to redesign your website.

This week I’ve booked out a chunk of time to redesign and rebuild my site from the ground up. The hope is that a fresh new site will provide the perfect platform to start writing and publishing again in the new year.

Here are a few of my thoughts as I start the project:

  • I’m sticking with WordPress and plan to fully embrace Gutenberg. I know there are lots of great platforms out there to choose from, but it makes sense to stick with what I know given that my business specialises in WordPress development.
  • I want the site to load as fast as possible. It will be minimalist in style and I’ll only include what is absolutely necessary.
  • I plan to use as little Javascript as possible and where I do, I’ll be using vanilla Javascript.
  • I’m going to stick with Sass. While I’ve enjoyed writing vanilla CSS again lately, there’s still a few things that I find useful: mixins, imports, etc.

The tools I’ll be using to build the website look something like this:

I’ll be “live designing” as I go, so the plan is to launch updates throughout the week. I’ll be sharing the process as I go.

December 15, 2019

Pyramid by Stuart Langridge (@sil)

I keep wanting this quotation and not being able to remember half the things in the list, so I’m putting it on my website: this is what websites are for.

It’s from The Official Slacker Handbook by Sarah Dunn, which I painstakingly tracked down and purchased a second-hand paper copy of to find this, and it reads:

Adam Weishaupt, founder of the Order of Illuminati, killed George Washington and served himself as our first president for two terms. The Illuminati are ultimately responsible for the French Revolution, the Bolshevik revolution, the American Revolution, the Pope, the Kennedy assassination, the Manson family, the Rockefeller dynasty, the numbers 5, 17, and 23, the New Age movement, the Nazis, UFO visitations, the Universal Price Code, and the pyramid with the eye on the back of the dollar bill.

No comment on whether I believe any of this, but of course that’s just what they want you to think. Fnord.

December 07, 2019

December 06, 2019

Reading List 244 by Bruce Lawson (@brucel)

December 04, 2019

December 03, 2019

Accessibility made the UK national TV news yesterday, hot on the heels of a report The business case for inclusive design by the UK disability charity Scope, which shows that around 50% of disabled people couldn’t buy something online that they wanted.

An accessible site is therefore a huge business opportunity, given that the latest Purple Pound estimate is £274 billion. (The Purple Pound a proxy for the purchasing power of the disabled community.)

Here’s a 4 minute interview on Channel 5 News to help persuade your bosses/ colleagues of the business case for accessibility.

Most of the problems that Glen talks about are easy to diagnose and solve. In fact, last week I wrote a handy Checklist to avoid the most common accessibility errors. Use it and make more money while being a better person.

Free online course!

If you want to learn more, as it’s International Day of Persons with Disabilities, W3C launched an Introduction to Web Accessibility free online course in cooperation with UNESCO. Enrol from today; the course starts 28 January 2020.

November 30, 2019

I recently had one of those moments where some code failed, but not in the way I expected it to. To create a contrived example, the scenario was basically this:

class LocationsController < ApplicationController
  def update
    my_location = Location.find(params[:id])

This code won’t do what I want it to because I have defined the variable my_location but then passed location to another method. What I initially expected upon finding the bug is that I would have seen a NameError complaining that the local variable location didn’t exist. But I didn’t. As far as I could tell, location existed and it was nil.

It wasn’t referenced anywhere else in LocationsController, nor in ApplicationController. So what is it? Fortunately, Ruby provides a great way to find out.

class LocationsController < ApplicationController
  def update
    puts method(:location).source_location
    # "/usr/local/bundle/gems/actionpack-"
    # 149

That’s that mystery solved. There is a method called location implemented a layer or two up the inheritance hierarchy. We knew it had to come from somewhere, but source_location lets us determine the exact location.

November 27, 2019

Fitness & Motivation

With the year speeding towards an end I wanted to write something about 2019 and how fitness saved my freelance career.

Oh yeah… this article contains pictures of me with my boobs out, apologies in advance.

It’s no secret that I love and hate freelancing in equal measures. I’m the first to admit I’m not always the best at keeping healthy attitude towards myself and my work. Ask any of my online buddies and they’ll probably tell you at least once where I’ve complained to them and commented on wanting to take a “proper job”

Get a “proper” job??

Well 2019 was the first year where I almost did get a proper job. I was talking to several startups about taking a role with them, at first it was a fun flirt with “what ifs” and quickly became real when I was being asked for salary expectation.

Before I really could accept any of these roles I had to remind myself of the 11+ years I’d been working as my own boss and ask myself “Why are you looking for a job?”

The answer was all about Motivation. I had none. 11 years of freelancing had worn me down and you know what, I wasn’t that 26 year old that started freelancing either.

You’re too old!!

Another huge factor was my age. Things were changing, I was struggling with my skin, back pains, anxieties – all sorts.

I assumed taking a role would take away all the stresses of being your own boss and give me that buzz to go to work… I quickly realised I’d still be me… just in another role so had to go deeper to the problem.

I read online that energy levels and motivation can easily be linked with how healthy you are… so I decided to try and get fit.

Let’s start running

My fitness journey started when we moved house. We had moved to lovely Shrewsbury where the River Severn runs through. I had always wanted to run around the river so started slowly by doing the Couch to 5k. It was starting to work – I had hit my 5k target earlier and even worked up to just under 8km and then, BOOM. Injured.

That was mid-late 2018. For 3-6 months I did nothing about it. I had also hurt my back doing manual labour in the garden. I felt like I was falling apart!

So now I had these injuries, this boredom at work and no motivation to get anything done.

Let’s lift some weights

My wife had started going to a ‘Strong Girls’ club that was 1 hour strength training sessions ran by a lovely local couple Simon and Suze. Their company Core Fitness / Studio Four also did mens sessions but I didn’t like the idea… at first.

It took my wife about 6 weeks of suggesting I went to the mens sessions before I finally agreed to go – and I loved it.

It was nice to get out of the house and talk to people that wasn’t my dog. I was working muscles I never knew I had and then BOOM. Injury, the bloody back went again.

Let’s see a professional

This time I took my back injury seriously, booked into 3 Osteopath sessions (which didn’t really work for me) and 3 Chiropractor sessions (Which thankfully did work for me). The diagnosis was a strained butt (not even joking) and a strained neck.

After the 3 sessions I was feeling back to feeling some level of normal and excited to get started on the fitness sessions again.

Let’s seek dietary advice

At the same time I spoke to Suze about my skin, as a nutritionist she quickly got to the bottom of my skin woes. I was eating too much crap, snacking on sugar based foods. Turns out 90% of my foods were bad for people like me with Eczema. Inflammatory! I shouted.

Lets eat clean-ish

I quit sugar, dairy and wheat and my skin slowly retuned to normal. Don’t worry gang, the weekends are fairly full of cheat meals but I’ve never gone back to dairy or wheat.

Sugar is the one area I still struggle with but even now I’ve reduced my sugar LOADS. I’m sure I’ll be rebooting my sugar levels very soon don’t you worry.

Let’s train!

So back to the training. I’ve been going now for a solid 6 months – stronger each session. I’ve even started doing some PT with Simon, the hour a week is great to just focus on my body and not worry about work.

So currently Monday is PT, Tuesday is Strength Training, Thursday is Circuits and Saturday is a home workout. I love it. I’m addicted to working out.

The results are incredible.

Regardless of how I look I was back in the zone, firing on all cylinders. I was fitter than ever and people were noticing that I was looking healthy. Even my mother in Australia notices it via a blurry Skype session.

My productivity was back up, my confidence was up. Even the anxieties I was having before are fading away – leaving the house regularly is good for you… who knew??

The new me has since doubled down on freelancing and began working with startups and tech businesses more long term, less about the 5 day projects and more about the 6-12 month engagements.

My work has improved and honestly enjoy getting to my desk in the mornings. Earnings are up and my accountant is happy.

To avoid future back problems I also treated myself to a Herman Miller Aeron chair and making more use of my standing desk.

So this is my journey in photos below. I wasn’t huge to begin with but you can see how unhealthy I looked.

So TL;DR – Exercising and eating better has helped me focus, gain confidence, reduce anxieties and find love for my job once more.

I’m fairly confident nobody is reading this far down the page but feel free to tweet me with your own fitness-freelance stories. #freelancefit

Cat Photo by FuYong Hua on Unsplash
Hiring Photo by Free To Use Sounds on Unsplash
Photo by Aarón Blanco Tejedor on Unsplash

The post Fitness & Motivation appeared first on .

November 26, 2019

Last week I was moaning about the fact that 63% of developers surveyed don’t test accessibility. And I was banging on about editing a ‘learn HTML’ book which was riddled with basic accessibility errors, when Frederik replied in order to shut my whining and make me do something about it:

This isn’t a comprehensive guide to accessibility, but we’ll look at ways to avoid the most common accessibility errors identified by the WebAIM accessibility analysis of the top 1,000,000 home pages, and the HTTPArchive 2019 Web Almanac analysis of 5.8 million pages. I’m not going to get philosophical; if you’re reading this, I assume you care about why, and just want some tips on how. (But if you need to convince someone else, here’s the 4 minute business case for accessibility.)

Insufficient colour contrast

83% of homepages have low colour contrast. There are several ways to check this. I personally use Ada Rose Cannon’s handy Contrast Checker Widget, which sits in my bookmarks bar like a useful Clippy and goes through the current tab and highlights where there isn’t enough contrast. Or you can use Firefox’s Accessibility Inspector in the devtools to check and tweak the CSS until you get a pass. To check a particular combination of colours, contrastchecker will give you AA and AAA ratings. will tell you which particular types of visual impairments may have difficulty with your chosen colours.

Missing alternative text for images

A whopping 68% of homepages had missing alt text (NOT alt tags). Every <img> must have alternate text. Here are basic rules:

  1. If the image is purely decorative, it must have empty alt text: alt="". But it should probably be in CSS, anyway.
  2. If an image is described in body text it should have empty alt alt="", to avoid repetition. But be careful if it’s an <img> in a <figure> (hat-tip to Mallory).
  3. If an image is the content of a link (for example, your organisation’s logo can be clicked to go to the homepage) the alternate text should describe the destination of the link. For example, alt="home page".

Heydon Pickering’s revenge.css bookmarklet does a quick and easy test to diagnose these, although I feel some of its other warnings are now outdated – I’ve filed an issue.

Empty links, empty buttons

I don’t know why anyone would do this, but apparently 58% of homepages tested had empty links, and 25% had empty buttons. I’m assuming this means they were empty of text, and contained only an image or an image of text. In the case of buttons, HTTPArchive Almanac says “often the reason this confusion occurs is due to the lack of a textual label. For example, a button displaying a left-pointing arrow icon to signify it’s the “Back” button, but containing no actual text”. (They found 75% of pages do this.) If that’s the case, the image needs alternate text that describes the function of the button or destination of the link. And don’t use icon fonts.

Use Heydon’s revenge.css bookmarklet to diagnose these.

Missing form input labels

52% of homepages had missing form labels. I prefer to wrap the label around its input like this:

<label>Email adddress: 
  <input type="email" />

I find it’s more robust than associating a form with a label using the for="id" pattern. If you can’t use an HTML label element, you can label an input for assistive technology using aria-label="useful instruction" or (less useful) a title attribute on the input. Use Heydon’s revenge.css bookmarklet to test these. WebAIM has more advanced form labelling techniques.

Missing document language

23% if homepages didn’t declare the human language of the document. This matters because (for instance) the word “six” is pronounced by a French screen reader very differently from an English screen reader. It’s simple to do: <html lang="en"> tells assistive tech that the main language of this page is English. The codes are defined in BCP47.

Missing <main> elements

The HTTPArchive study of 5.8million pages shows that only 26% of pages have a <main> element and 8.06% of pages erroneously contained more than one main landmark, leaving these users guessing which landmark contains the actual main content.

Solution: wrap your main content, that is, stuff that isn’t header, primary navigation or footer, in a <main> element. All browsers allow you to style it, and assistive technologies know what to do with it.

Happily, more than 50% of pages use <nav> <footer> and <header>. In my opinion, <nav> should go around only your primary navigation (and can be nested inside <header> if that suits you). In its survey of screen reader users, WebAIM found that 26% of screen reader users frequently or always use these landmarks when navigating a page.

Here’s a YouTube video of blind screenreader user Leonie Watson talking through how she navigates this site using the HTML semantics we’ve discussed.

YouTube video

There’s lots more to accessibility, especially if you have lots of JavaScript widgets and single-page application architecture. But my list will help you to avoid the most common accessibility errors and become a web superhero adored by millions. Moritz Gießmann has a nice single-page Accessibility Cheatsheet.

You can also make tagged accessible PDFs from your pages using Prince—it’s free for non-commercial use. If you’re one of the React Kool-Kidz™, I recommend using Tenon-UI: Tenon’s accessible React components library.

Buy me a pint when you see me next. xxx

Dive deeper?

The single source of truth is Web Content Accessibility Guidelines (WCAG) 2.1 from W3C. UK’s Government Digital Service has a good readable Understanding WCAG 2.1 guide. For advanced applications requiring ARIA, I find W3C’s Using ARIA invaluable.

You want tools? The BBC has open-sourced its BBC Accessibility Standards Checker. Google Lighthouse and are also very good. Please note that no automated tool can be completely reliable, as the fun article Building the most inaccessible site possible with a perfect Lighthouse score demonstrates.

If you want a self-paced course, on International Day of Persons with Disabilities, W3C launched an Introduction to Web Accessibility free online course in cooperation with UNESCO. Enrol now; the course starts 28 January 2020.

It’s common in our cooler-than-Agile, post-Agile community to say that Agile teams who “didn’t get it” eschewed good existing practices in their rush to adopt new ways of thinking. We don’t need UML, we’re Agile! Working software over comprehensive documentation!

This short post is a reminder that it ran both ways, and that people used to the earlier ways of thinking also eschewed integrating their tools into the Agile methodology. We don’t need Agile, we’re Model-Driven! Here’s an excerpt from 2004’s UML 2 Toolkit:

Certain object-oriented methods on the market today, such as The Unified Process, might be considered processes. However, other lightweight methods, such as Extreme Programming (XP), are not robust enough to be considered oricesses in the way we use the term here. Although they provide a valuable set of interrelated techniques, they are often referred to as “small m methodologies” rather than as software-engineering processes.

This is in the context of saying that UML supports software-engineering processes in which a sequence of activities produce “documentation…about the system being built” and “a product that solves the initial problems is introduced and delivered”. So XP is not robust enough at doing those things for UML advocates to advocate UML in the context of XP.

So it’s not just that Agilistas abandoned existing practices, but there’s an extent to which existing practitioners abandoned Agilistas too.

November 25, 2019

Stop Playing Yourself

Ten traps that are stalling your digital project, and how to avoid them.

Millennial thought leader DJ Khaled popularized the phrase ‘Congratulations, You Played Yourself’ in 2015, but I like my hip-hop a bit more conscious, so for me the phrase originated in 1996 in a deep cut from Jeru The Damaja’s sophomore album “Wrath of the Math’, that track being, of course, ‘Ya Playin’ Yaself’.

Turning to the Urban Dictionary for a definition we find that to play oneself is to:


I think about that a lot when I think about big digital projects. Projects like designing and building a new website. We all start these projects with huge enthusiasm and strategic intent. And yet so often, by the time we launch, we’re a little bit ‘meh’. Perhaps - after all that money and effort the needle doesn’t move all that much. What we have now is a lot like what we had before, but with more in vogue typography.

Why is that?

In my experience it’s because we just can’t help playing ourselves. On lengthy digital projects, we have far too many opportunities to let instant gratification or bad habits sabotage our strategic goals. We play ourselves. I want to help you to recognize when you’re playing yourself, and to arm you with some tactics so that you can stop.


I’m going to do that, by describing ten traps that I often see cultural organisations fall into, and suggesting some tactics for getting out of them.

Trap #10 Building a Monument
Trap #9 100% Digital Coverage
Trap #8 Divide & Conquer
Trap #7 Designing for your CEO’s smartphone
Trap #6 False Prophets
Trap #5 Post-it Fetishism
Trap #4 Building not Buying
Trap #3 Buying not Bodging
Trap #2 Bogus User Stories
Trap #1 Cutting Against the Grain

Trap #10: Building a monument

In most digital projects we are trying to build services that your patrons want to use. We have known for many years that users interactions on the internet are overwhelmingly task-driven. They have an outcome in mind, whether that’s a ticket, a customer service issue, confirmation of a piece of information, a subscription, whatever. They want to take the shortest route possible to get that task done.

As internal stakeholders though, we really value what we do. Of course - it’s our chosen profession, hopefully the thing we’re most passionate about. And our organizations represent the aggregation of all that passion. So inevitably, whilst we start out trying to design great customer experiences we are liable to overestimate how invested the end user is in our organisation at that moment, and to start believing that the user is here to find out more about us, in an abstract sense.

Before you know it, you’ll see that efforts have subtly shifted from helping our users to succeed, toward building a monument to our organisation. There are certain tell-tale phrases that I look out when I think we might be transitioning into building a monument. One of them is

“There’s so much we do here that we just don’t talk about”.

Do you know what the archetype of this is? It’s that sad Education or In the Community section, where we list all of the programs we run in one place; even though each of those programs is specifically targeted at a different end-user profile, and there are limited opportunities to engage digitally with those programs.


Another way this trap manifests is in redundant top-level navigation. When we start to see our digital assets as monuments to the organisation, navigation becomes about exploring all of the facets of the organization, rather than facilitating the common tasks that users are trying to achieve. This results in navigation where 80% of the traffic is verifiably directed to just one of the seven top-level navigational items. I’ll come back to this.

Congratulations - You Played Yourself

Some tactics to prevent you from building a monument:

  1. At the start of the project as well as agreeing objectives agree those things that are your anti-objectives. We are not setting out to build a monument to the organisation. Every time you’re about to add a requirement to a backlog, ask yourself - are we building a monument? Encourage your team to ask that question, and give kudos for resisting the sentiment.
  2. Find more appropriate outlets for this content. Your organization’s history probably makes for a very worthwhile Wikipedia entry and it’s a better trusted source for people who are genuinely interested. Personally, if I’m researching a topic I skip the official site, and go straight to the Wikipedia entry that is usually to be found at SERPs position 2. Because I know what I’m going to get. Go wild on Wikipedia. No-one’s stopping you. If you need to compile an overview of all the great work you do, because this content is targeted at a very specific end-user - eg, a charitable trust, then create a document, or a video especially and send it to them. There’s nothing to stop you from linking out to both of these assets from your digital project.
  3. Obviously, if you have a heritage lottery fund to fund a digital archive project, building a monument is the objective, so you can cheerfully ignore everything I’ve just said. In fact do the opposite.

Trap #10 Building a Monument
Trap #9 100% Digital Coverage
Trap #8 Divide & Conquer
Trap #7 Designing for your CEO’s smartphone
Trap #6 False Prophets
Trap #5 Post-it Fetishism
Trap #4 Building not Buying
Trap #3 Buying not Bodging
Trap #2 Bogus User Stories
Trap #1 Cutting Against the Grain

Trap #9: 100% digital coverage

Many well-meaning digital and customer service people are of the opinion that if your organisation offers a service to patrons it stands to reason that users should be able to self-serve over digital channels. The phrase it stands to reason is dangerous because it abdicates responsibility for research and for using our resources wisely where they will have the most impact.

I’ll give you a clear example that we come across time and again. You’re two thirds of the way through some major web build, and suddenly someone remembers the scheme. It’s some kind of youth access scheme that the artistic director came up with a few years ago. Twenty young people (or to be more accurate, their parents) took it up last year. Everyone knows that the scheme should be cancelled, but no-one has the authority to make the call, or the desire to plead with the Artistic Director. So now, when you should be QAing your major web build, what you’re actually doing is building a dedicated application that includes identity checking, parent-access accounts, the whole nine yards, to be used by approximately twenty people. It costs £20K to do it. You’re spending £1,000 per user to subsidise 4 tickets each with a total value of £200.

Congratulations - You Played Yourself

Some tactics:

  1. Let’s let go of the idea that everything you do should have a digital interface. Let’s treat our in-demand, hard to recruit and retain digital resource carefully. Before we start considering anything a requirement, let’s ask - how many people are using this service? What’s it costing per user to digitize this service? There’s actually a simple formula you can use: 

    Manual_task_in_hours_per_week * Salary * 1.3 / 38 > Development_cost / Lifespan_in_years ? 
    2 hours per week * 35K * 0.0342 * 5 = £12,082 

    So in this case if a manual task took someone earning £35K two hours per week, you need a development cost well under £12K to make it worthwhile digitizing and it will take five years to earn that value. And guess what - code needs maintaining too, there will be maintenance, hosting, changes to browsers and legislation. So a degree of human intervention will always be required.
  2. By the way - this doesn’t just hold for customer-facing stuff. Your own digital team will instinctively want to automate lots of things that aren’t even customer-facing too. Is it justified on a cost basis? You should check. Digital staffers are kind-of the opposite of luddites, they find manual tasks offensive, even when they’re being paid to do them.
  3. It might be outside of your control to close a scheme with few users. But you might reasonably say that the number of users is too small to justify the digital development. Make that scheme ‘concierge only’. Service it through phone or chat interfaces.
  4. I’d extend that thinking to anything legacy. And you might be surprised by what I’d consider legacy: Direct Debits, Microsoft Edge, Desktop Computers, Paper Tickets

Yes people still use these things now. But are you confident that it’s worth investing in them now for your new digital project, based on a 5 year lifespan?

Trap #10 Building a Monument
Trap #9 100% Digital Coverage
Trap #8 Divide & Conquer
Trap #7 Designing for your CEO’s smartphone
Trap #6 False Prophets
Trap #5 Post-it Fetishism
Trap #4 Building not Buying
Trap #3 Buying not Bodging
Trap #2 Bogus User Stories
Trap #1 Cutting Against the Grain

Trap #8: Divide & conquer

I think by now we’re probably all aware that you’re not supposed to structure your top-level navigation based on your organisations departmental structure. 

And yet - that’s still really common actually, we just swap the department names for their customer-facing equivalent, Fundraising becomes Support Us. That’s why the biggest IA challenge on most projects is deciding what the correct customer-facing term for the Education department section is. Learn? Interact? Dive In? Explore? Go Wild?

But even if we’re not doing that. How do we figure out what our website requirements are?

Usually, we draw together the departments, so that they can take turns reciting their wishlists. This is setting off on the wrong foot for a couple of reasons.

  1. Departmental thinking leads to bad UX. If you ask a fundraising department what they’d like from the website, maybe they think every transaction should be interrupted with a colossal donation ask. Maybe that impacts on ticketing revenue, but why should they care? And vice-versa.. The person responsible for the overall UX needs to look at the total revenue to find the best compromise. They can’t be thinking on behalf of one department.
  2. Not all departments have the same exposure to end-users, revenue or technology. But by treating requirements gathering as a round-robin departmental exercise all are elevated to the same status in digital terms, regardless of the objectives of the project. This process encourages departments to think of elaborate features that their users might like, without necessarily user testing any of this, or without any reference to a cost-per-user or cost-per-revenue calculation.

Often, the department leading the project, has no real intention of delivering these features. However, they never explicitly reject them, so they crowd development backlogs and schedules until they are finally ‘back-burnered’, causing disappointment and distrust. So to get over the trust issues, the disappointed departments are consulted on the next big project and the cycle starts up again.

Congratulations you played yourself.

Here are some tools:

  1. Figure out which department is actually responsible for the project. If it’s a dedicated digital department, answering directly to someone on the board, so much the better.
  2. Be clear about the organizational objectives for the organisation and name them in real, user-focused terms.
  3. Invite departmental heads, and maybe some of their operational people to contribute to requirements gathering. But not as the representative of their department. They are there as domain experts to help refine the overall requirements. Smart people can work for the objectives of the overall organisation, and will have real insight into how things work, things that are easy to contribute, small changes that could have big impacts for them. That’s what we want.

Trap #10 Building a Monument
Trap #9 100% Digital Coverage
Trap #8 Divide & Conquer
Trap #7 Designing for your CEO’s smartphone
Trap #6 False Prophets
Trap #5 Post-it Fetishism
Trap #4 Building not Buying
Trap #3 Buying not Bodging
Trap #2 Bogus User Stories
Trap #1 Cutting Against the Grain

Trap #7: Designing for your CEO

One of our local rivals has a question on their client-engagement survey: “What Smartphone does your CEO use?”. Any digital agency project manager will immediately realize why they do that, and it’s a pretty smart move. You see they’ve seen plenty of carefully-researched, strategic digital projects de-railed at the last moment, because the organization’s CEO took a look at it on their Blackberry Classic Q20.

Everyone on the digital team was clear about which browsers and devices they would be supporting, and this particular model does not represent a rounding error on the end-user analytics, but it doesn’t matter, because this is the only end-user that really counts at this moment in time.

It’s not just devices. I’m a CEO. Do you know how I got to be one? Well I’m not shy in coming forward with opinions. You ask me to feed back on something, I’m ready to go with feedback. Oh you want considered feedback? I don’t have time for that, I’m an executive.

You know what else I’ve got? Ideas - so when you show me your carefully-crafted digital project scheduled for launch next week, I’m not going to pat you on the head for a job well done. I’m more likely to ask you why it’s not Spanish bi-lingual. Oh - you think that’s unreasonable? You don’t get to be CEO by doing what’s reasonable. I’m including Artistic Directors here by the way.

It’s quite easy for digital teams to start high-fiving each other, because they’re being user-centered, using all the latest techniques and jargon, getting lots of validation from their piers, and feeling really good about where they’re going, but totally forgetting to take management with them.

Congratulations you played yourself.

Here’s what you should do:

  1. Engage early and engage often.
    One of the most frustrating things about engaging with upper management, is that they have plenty of opinions, but seem strangely reluctant to take decisions. They seem to sketch out a world of possibilities, and leave you to join the dots. Here’s the secret; management are asked to take decisions all day long and they are tired of it. So stop asking for feedback, but keep management appraised of the decisions you are taking. If one of those decisions is directly in opposition with their strategy they’ll let you know, and you can course correct. I suggest you present monthly if possible. Keep it really quick and top-line. “We’ve decided our top three goals are X”, “We’re aiming to increase Y by Z in-line with our mission”
  2. Take note of feedback.
    When you get opinions and feedback regardless, take note, and think about how you are going to pay lip-service to them in your next presentation. If the CEO said they don’t like dark backgrounds, find a page with a light background and screen-shot that one for your presentation. If the CEO said it needed to be dual-language don’t laugh that off as unattainable, figure out a range of options and coverage, from telling the user to try Google Translate to guesstimating the true cost of doing it properly. Be ready at the next meeting to drop in those considerations, and tie them back to their original request. CEOs might have temporarily forgotten their previous feedback. If you showcase the ways in which you’ve taken it on board, that will help fend off new, entirely contradictory feedback. And whilst CEOs might be ready at all times with ill-founded opinions, they usually respond well to well-researched options. So come back with evidence.

Trap #10 Building a Monument
Trap #9 100% Digital Coverage
Trap #8 Divide & Conquer
Trap #7 Designing for your CEO’s smartphone
Trap #6 False Prophets
Trap #5 Post-it Fetishism
Trap #4 Building not Buying
Trap #3 Buying not Bodging
Trap #2 Bogus User Stories
Trap #1 Cutting Against the Grain

Trap #6: False prophets

You know this guy? He’s Shingy. AKA David Shing. His job title was Digital Prophet at AOL from 2011 to 2017. He now works at Verizon, where his job title is… Digital Prophet. He’s very much digital’s answer to DJ Khaled.

He does look a bit like he’s stepped out of The Matrix, and I guess that might be what you want your digital guru to look like. I actually watched one of his videos in preparation for this, and guess what, he has some totally reasonable and well founded opinions about things. But fundamentally he shows up at conferences and tries to see into the future. When you think about it, there’s nothing new about employing futurologists. Today they make pronouncements over Twitter, two thousand years ago, they’d be communicating via chicken entrails.

I think a lot of us get quite a lot out of conferences, they’re a safe-for-work way of expanding your mind, and we all leave feeling a little more enlightened. You don’t get an interesting conference talk by telling people that they’ll get best results by tracking progress, and working diligently to course correct. You’ll get a lot more traction telling people that no-one ever visits home page or whatever. That’s a gross oversimplification by the way. But no-one’s got time to put across subtle arguments at a conference.

And I think that’s why it’s so tempting. If you want to expand your mind, sometimes the best way of doing it is to step outside your day to day into a parallel universe where all the rules are different. Sometimes developers do it by switching programming language. It’s a way to rejuvenate your interest, but it doesn’t mean everything you learned before is wasted.

The problem comes, when you hear someone speak, and get so blown away that you decide that you have found your Guru, entrusting your digital operations to that individual by getting them to set up your team, or run your RFI. I come across this a fair amount. Someone might have got off to a good start at a major media organisation. They’ve jumped around as a consultant ever since. They’ve maintained their contacts, but always seem to jump ship just before the thing they were working on actually gets delivered.

Now they’re running your digital processes. They insist the product has to be built on a new obscure functional stack that’s going to 10X your productivity. They invite their cronies to pitch for your RFP. They keep trying to apply big media strategies to your organisation. They wind-up your staff with their impractical opinions. They’re constantly on their phone lining up their next appointment before the shit hits the fan.


Congratulations you played yourself.

Here’s how to avoid this.

  1. Be wary of putting one-man/woman bands in charge of your strategy. You’re likely to be getting one person’s very biased opinion.
  2. When checking references, look beyond the strategic interventions, and ask about outcomes. Yes, they ran a report, or a process, but what were the outcomes of that in the real world? Did the process lead to a tangible output? Was the consultant still around to see it?
  3. Maintain a large list of influences. I follow people on Twitter who are agile advocates, I also follow people who think agile is killing the art of software architecture, people who think it’s inhumane to deploy on Fridays, people who think your organisation is failing if it can’t. It helps me to take on-board new ideas, without falling for hype. Getting outside my comfort zone and seeing things from different perspectives without slavishly following trends.

Don’t get misled by False Prophets, just follow what I do.

Trap #10 Building a Monument
Trap #9 100% Digital Coverage
Trap #8 Divide & Conquer
Trap #7 Designing for your CEO’s smartphone
Trap #6 False Prophets
Trap #5 Post-it Fetishism
Trap #4 Building not Buying
Trap #3 Buying not Bodging
Trap #2 Bogus User Stories
Trap #1 Cutting Against the Grain

Trap #5: Post-it fetishism

I sometimes think that, women staring intently at post-its is the new women laughing at salad. It’s a stock image cliche.

You know when you get the web designers in? They always turn up with the Post-its don’t they? It’s a lot of fun. Things get messy. In a good way. Ideas everywhere.

You go back to your desk at the arts org. Another pissed-off patron. A round of chasing decent images for the season brochure. You wonder what it’s like back at The Web Design Company? They’re probably having a lot of fun there, in that meeting room that’s done out to resemble a Swiss Chalet. They’re probably writhing naked on a conference table covered in post-it notes by now. Sniffing the little adhesive strips. Turns out this image is a stock-photo deadzone.


You get to thinking; That looked pretty easy, I could do that. I’m going to set up a team of in-house post-it fiends. Or at the very least, I’m taking control of the post-its, no reason that the web designers should have all the fun.

You buy your own packs of stickies, and recruit a few people to push them around the columns. It starts out great, just as you dreamed. Everyone’s really happy. But as time drags on, management start asking questions. They loved the post-its too, but wasn’t there supposed to be some kind of actual digital output associated with this project? They thought going digital was supposed to save on paper?

You start by digitizing the post-its. You put them on Trello. This is almost as fun to start with, but then slowly, it all starts to go downhill. The digital post-it notes just proliferate. Because they’re digital, you can fit loads more writing on them, and they just start to get longer and longer, flame wars break out in the comments, and the damn post-its won’t move. The people in the basement who are supposed to put them in the ‘done’ column have stopped playing ball. They’re swearing off post-it notes altogether and trying to get clean by going on yoga retreats. It’s like the end of the 60s. The dream has died.

Congratulations you played yourself.

Here’s the dirty secret. We just bring the post-its in, because we know they break down barriers, and encourage bonding. It’s the equivalent of turning up to dinner with a bottle of wine. Just a token, that’s all. Here’s what you need to do:

  1. I don’t care how agile your project, or product is. There will be a green-field envisioning phase, and then, at some point, it’s going to turn into a long slog. Lots of bugs, plenty of technical debt. You need to prepare for a marathon, not a sprint (pun intended).
  2. You need to be mindful that every post-it note you place on the board, is someone’s technical debt six months, or six years down the line. Even if you put an idea on a post-it into the Won’t column, it will still take up mental energy and clog up your future Kanban boards.
  3. Try to solve real problems tomorrow with simple solutions. Don’t build complicated solutions to theoretical problems.

Trap #10 Building a Monument
Trap #9 100% Digital Coverage
Trap #8 Divide & Conquer
Trap #7 Designing for your CEO’s smartphone
Trap #6 False Prophets
Trap #5 Post-it Fetishism
Trap #4 Building not Buying
Trap #3 Buying not Bodging
Trap #2 Bogus User Stories
Trap #1 Cutting Against the Grain

Trap #4: Building not buying

Once you assemble your big expert team, led by a guru, and armed with all the different post-it colors, what you really need to get the blood flowing is a big project. Something that requires you to spend a good while evaluating the myriad JavaScript frameworks (and pick React like everyone else). Something that requires a big capital grant. Something, that you could buy off the shelf?

Ah - but we’re not going to do that are we? The big generic product is great, but it’s just not quite what we’re looking for. There’s 20% of functionality that we really need. It’s pretty subtle stuff, it’s the stuff that makes us unique.

Two years later, you’re still trying to build the 80% of functionality that the generic platform has, whilst the platform vendor has been busy developing the 20% you thought you needed. Meanwhile digital progress has totally stalled in your organisation. No-one implements quick fixes to problems today, because ‘the new platform’ will do it all, and it’s nearly there now honestly…

Congratulations you played yourself.

  • Take the time to understand the platforms that are available to solve these problems. Quite often, when I hear that an organisation has unique challenges, it turns out that they haven’t really taken the time to understand how a platform can be configured to support those needs. Configuring a complex platform to be just right for your organization can take a long time and a lot of patience, even more so if people are already using it the wrong way. But it’s never as much effort as building a platform from scratch.
  • Re-think some of what you do to suit the product. It’s OK for the tail to wag the dog a little here. Software investment can be a huge overhead. Especially if you’re building it from scratch. If you were to elevate those concerns to board level and make a true cost consideration, would the organisation actually change some of the things they do to suit the software? 

What if marketing looked at what types of promotions and offers their platform made easy to facilitate, and set up around those. Instead of thinking up (sending to print) schemes and asking the digital people if they were ‘possible’.

This runs antithetically to the idea of IT as a service department, but that’s the whole idea behind rebranding it as Digital.

Trap #10 Building a Monument
Trap #9 100% Digital Coverage
Trap #8 Divide & Conquer
Trap #7 Designing for your CEO’s smartphone
Trap #6 False Prophets
Trap #5 Post-it Fetishism
Trap #4 Building not Buying
Trap #3 Buying not Bodging
Trap #2 Bogus User Stories
Trap #1 Cutting Against the Grain

Trap #3: Buying not bodging

But then, sometimes the opposite instinct takes charge. I’ve got to say that often this instinct arises in the IT department. IT departments attract people who like big tools. It’s part of the procurement culture. We get excited by feature checklists. 

I see this play out the most when big, generic products are bought to solve relatively simple, domain-specialist tasks. Huge vendor Content Management Systems. Personalisation Engines. Recommendation Engines, Loyalty Schemes. We want the gold standard, but sometimes these products are designed to do very simple things on huge data sets, whereas many of the organizations Made works with have hugely complex, but relatively small data-sets.

So you do a huge checklist vendor comparison, and negotiate a chunky charitable discount on a big-vendor solution. You spend months implementing it. You’re only actually using it to send thank-you emails at the moment, but you’ve barely touched the surface. There’s all that power thrumming under the surface. Like buying a Lamborghini and using it solely for the school-run. Of course the performance requirements of that engine mean that it’s always overheating and taking down your web stack.

Congratulations you played yourself.

Think about the problems you really want to solve, and the shortest route to solving them. Forget the me-too features, and think about where your data is and where you want it to be.

  • Maybe the in-house skills you really need are plumbing skills. The ability to do effective joining up of your disparate systems. Some basic SQL and API skills can go a long way in achieving this.
  • Let go of the idea that everything has to be perfect to be worthwhile. Better to handle a little manual process replication and deliver a thing today, than to spend two years configuring the perfect one true database, and find that no-ones interested in the product. If you get something out today, that just about works, you can invest in improving it if it takes off.

Trap #10 Building a Monument
Trap #9 100% Digital Coverage
Trap #8 Divide & Conquer
Trap #7 Designing for your CEO’s smartphone
Trap #6 False Prophets
Trap #5 Post-it Fetishism
Trap #4 Building not Buying
Trap #3 Buying not Bodging
Trap #2 Bogus User Stories
Trap #1 Cutting Against the Grain

Trap #2: Bogus user stories

When we first swallowed the manual on user-centred design. we used to get quite excited over our personas. Here’s one, Henry he has a whole side plot about his divorce, and how it’s impacted on his relationship with his grand-kids. Very relatable. I think we were working through our purple patch here. We started out with much thinner, paperback characters, they had star-signs, but you couldn’t really figure out their motivation in hitting the checkout button.


Anyway - we’ve got a lot more functional recently. Character names are much more likely to be along the lines of ‘Single Ticket Buyer’’. Whatever, they’re called, they are not likely to feature in user stories like this:

[story] “As a Patron I want to Engage with rich content about education projects so I can feel more involved.”

That - I am afraid - is a Bogus User Story. These are the stories we end up writing when we are trying to make the users fit into the motivations of our organisation. You’re basically starting with those departmental round-robin requirements, and trying to put them into user story format. You see that bit at the end of the user story. The ’So I can’ bit? That bit is the most important piece of a User Story because it’s supposed to establish the benefit to the user, and hence the reason they would want this feature. When you have a long-list of internally generated requirements this gets annoying pretty fast. Who are these people? What do they want? It just gets in the way…

So you end up with Bogus User Stories, and because of that the people at the coal face delivering the features:

  1. Don’t know how to build the feature (because User Stories don’t really tell you)
  2. Don’t know what the feature is for (because the story is bogus)

Congratulations you played yourself.

What do do:

  • You could Keep it Real, by asking actual users for things they want to use your website to do. If you actually ask real people, they might start telling you about things they think they might want, rather than things they need, so even better, you could observe real users using a tool like HotJar or Full Story, or run an actual task-focused user test.
  • I recommend taking a look at the Jobs To Be Done framework. Jobs To be Done is quite interesting. It’s not designed as an out and out replacement for User Stories, but it does have some things to say about Personas. It presumes a user has a job to do, and considers how your product will facilitate that job. If we think about the job of attending a show, and then consider all of the things that out user needs to do in order to get that job done, it will give us clues as to the main tasks our website should facilitate, from researching the shows and times, to entering their credit card details, to getting directions to the venue. The why is embedded in the job to be done, the how is your job to figure out. You might find it helpful to view your product from that perspective as a parallel to your user stories. At the end of the day, when you think about the jobs you have to do, it doesn’t make that much difference if you’re a divorced Libra or not.

Trap #10 Building a Monument
Trap #9 100% Digital Coverage
Trap #8 Divide & Conquer
Trap #7 Designing for your CEO’s smartphone
Trap #6 False Prophets
Trap #5 Post-it Fetishism
Trap #4 Building not Buying
Trap #3 Buying not Bodging
Trap #2 Bogus User Stories
Trap #1 Cutting Against the Grain

Trap #1: Cutting against the grain

In 1996, the year Jeru the Damaja released Ya Playin Yaself, if you wanted to pick up a copy on vinyl, from an ecommerce store you would use a search engine. 

The dominant search engines of the day were Yahoo, Lycos, Excite and Alta Vista. There was a new kid on the scene though because that year, two Stanford computer science PHDs, Larry Page, and Sergey Brin released a new search engine called Backrub, which would later became Google, sweeping aside its competitors in a little over two years with little to no marketing budget.

Do we know why it was called Backrub? That’s right, this was the original concept behind the page-rank algorithm you know and love today. At its heart, this was based on a very simple idea, which was that you could intuit the accuracy of a page in relation to a term, based on how many websites linked to that page using similar terms.

The other search engines, were building ever more complex lexical parsers. In addition, to cover up for the dubious accuracy of the search results, they were busy building directories and media services, trying to add value through a weight of human effort focused around but not on the core technology.


When Google came out it was devastating to those search engine companies, because not only were Google’s results much more accurate, but the user interface was far simpler, because they had faith in the underlying algorithm.

I like to think that the reason Google achieved dominance over the other search engines so quickly, was because they cut with the grain of the world wide web whilst their competitors were cutting against the grain. They built upon the way the web fundamentally worked, instead of trying to graft huge computer science and content marketing effort onto it. They took a colossal short-cut, but like all the best technology, it seemed indistinguishable from magic to the end user.

Many of the most jaw-dropping technical advances, are actually quite simple concepts that occur to an engineer as a shortcut. But when we start digital projects we often ignore these shortcuts, because engineers are absent from the envisioning stage. Instead, we imagine vast, complex difficult to achieve products, because we’re not familiar enough with the underlying medium for those short-cuts to occur to us.

Think about gathering requirements from users, from departments, writing them diligently onto post-it notes, throwing them at a designer, debating the ins and outs, refining and then finally sending them downstairs to engineers, to build out this wondrous product. The trouble is, the thing you’ve envisaged cuts against the grain. It’s hard to build, it takes five times more budget, it’s devoid of pleasure. It’s going nowhere.

Ya Playin’ Yaself

  • Try asking someone a little closer to the data. Ask an engineer - what’s an easy thing we could do, with what we have today? Minimum effort and maximum impact. Ask someone with a reasonable grasp of UX, and a reasonable grasp of code. A technical human. They might surprise you with the cool things they can do, that are a lot less effort than you thought.
  • Google institutes 20% time to ensure that products can still emerge from the minds of engineers. What’s your organisational equivalent?

Trap #10 Building a Monument
Trap #9 100% Digital Coverage
Trap #8 Divide & Conquer
Trap #7 Designing for your CEO’s smartphone
Trap #6 False Prophets
Trap #5 Post-it Fetishism
Trap #4 Building not Buying
Trap #3 Buying not Bodging
Trap #2 Bogus User Stories
Trap #1 Cutting Against the Grain

November 22, 2019

Reading List 243 by Bruce Lawson (@brucel)

It’s been a busy week for one of the projects I’m involved with, along with my old chum Håkon Wium Lie (co-creator of CSS). Prince is a software package that produces beautiful, accessible PDFs from HTML, SVG and CSS. On Tuesday we released Prince 13 with support for CSS variables (aka custom properties), lots of goodies for non-Latin scripts like Arabic & Indic, & support for fragmenting single-column/row flex containers across multiple pages. Give it a whirl if you need to produce PDFs – it’s free for non-commercial use.

Then the next day, we open-sourced our Allsorts font parser, shaping engine, & subsetter for OpenType, WOFF, and WOFF2 under the Apache 2.0 license so everyone can have better Chinese, Japanese, Korean, and Indic scripts in PDF. Allsorts was extracted from Prince and is implemented in Rust.

November 20, 2019

A powerful platform for wealth managers

Multi award-winning account aggregation software, moneyinfo is the client portal that delivers clients’ secure access to their entire financial life in one place all beautifully presented under your own brand.

I’ve been doing some consultancy work with moneyinfo for quite a while now. I’ve started by giving their software a modern refresh and since moved onto their app designs, desktop designs and plenty of other areas of the business that needed some UX and UI assistance.

The team at moneyinfo are really smart and never reject any of my ideas before I’ve presented them.

They are really open to the idea of bringing in modern design ideas into their business.

The project can be tricky at times due to how much white labelling is needed within their brand. Each element needs to be considered for multiple colours and components are highly customisable which means no two screens will look the same.

Find out more about money info on their website.

If you like this design please share and if you’re in the market to book a freelance UI designer don’t hesitate to contact me.

The post MoneyInfo App Design appeared first on .

A community of news, events and offers in your phone

PostBoard is a platform for the curation, sale and sponsorship of digital content linked by a common theme and often tied to a common geolocation.

PostBoard founder Saqib Malik came to me with this really interesting idea for a local community app, he wanted the product to really speak to small communities. The app focuses on three main areas, offers, news and events. The app was designed to be highly searchable and promote local businesses.

PostBoard UI Design

Saqib had a really great eye for design and knew what he wanted to see from the start.

We worked closely to design an app that was simple to use but had a smart modern look.

Make sure you check out PostBoard if you’re in London, sign up for more information on their website.

If you like this design please share and if you’re in the market to book a freelance UI designer don’t hesitate to contact me.

The post PostBoard UI & UX Design appeared first on .

November 15, 2019

Imagine starting your day realising that someone found an outdated dependency in your project, upgraded it, opened a pull request with a detailed description and the test suite had already been run. All that was left was for you to do is carry out a code review and hit that merge button! That someone is Dependabot.

Why keep your dependencies up to date?

It is very important to keep your project’s dependencies up to date for 2 reasons:

  • The latest version is usually the best one (new features, better security, improved performance and bug fixes)
  • Iterative improvements are better than big-bang changes

Plus it is really satisfying when the project is up to date.

How to keep your dependencies up to date

One way would be to regularly ask your package manager to list out all the outdated dependencies. Upgrade them one by one, by checking the changelogs and then opening pull requests for each of them.

The better way is to have Dependabot doing all of that work for you. Dependabot pulls down your dependency files and looks for any outdated or insecure packages. It then opens individual pull requests to update each outdated/insecure dependency, with the changelog and release notes for each pull request and the test suite already executed, leaving just a review for you to do before hitting merge. That seemed like such a good idea to us here at Talis, that we’ve implemented this approach across many of our repositories.

Configuring Dependabot

Simply jump on the Dependabot app in Github marketplace and set up a plan (don’t worry, it’s free!). Then you will get a nice dashboard to configure Dependabot settings. At Talis we are using a configuration file placed in the root of the repo .dependabot/config.yml for Dependabot configurations.

Dependabot has a lot of configuration options. Some of the important and useful ones are

  • package_manager: What package manager to use
  • update_schedule: How often to check for updates
  • default_reviewers: Reviewers to set on pull requests
  • allowed_updates: Limit which updates to allow e.g security updates only, top level dependencies only
  • version_requirment_updates: How to update your package manifest (e.g. package.json, Gemfile etc)

These options can be configured per repo. You can find all the options here.

Then there are some account level settings in the Dependabot app which are applied on all the repos. Some of the important ones are:

  • Automatically rebase PRs: We have that turned off, as we do not want Dependabot kicking off new builds all the time
  • PRs rate limit: Limit of initial pull requests created for new projects. It’s a good idea to tweak this before adding Dependabot to any repo, so you aren’t overloaded by pull requests

This is what a PR created by Dependabot looks like:


The PR includes a very pretty description of the changes included. Dependabot also aggregates everyone’s test results into a compatibility score, so you can be certain a dependency update is backwards compatible and bug-free. There are also some commands which can be used to perform certain actions on the PR e.g rebase, recreate.

Dependabot and Github Security Alerts

Github also uses Dependabot with their security alerts. You get a “Create automated security fix” against an alert in the security tab of your repo, which uses Dependabot to create a PR to upgrade the insecure dependency.

This comes with some caveats at the time of writing this:

  • Creating an automated security fix from this section does not pick up the configurations you have defined in your repo for Dependabot
  • Github security alerts doesn’t seem to notify about sub-level dependencies for npm-shrinkwrap.json, whereas Dependabot does

To conclude, if you would like to automate your dependency updates, Dependabot is for you. And yes, we are on the right path to be taken over by bots.


November 14, 2019

November 12, 2019

Aldi (like Lidl) is a strange store. Not content with simply offering cut price groceries, if you manage to walk out of the store without a brand new HD TV, a WIFI-extending double power socket, and an inflatable dingy in your bag with your 17 tins of bakes beans, you’ve got more resolve than I.

The middle aisle, as it is known, is a constantly rotating stock of goodies available at bargain prices. With everything from baby toys to inverter generators, it’s not a surprise to see it often has a wide range of tools under their Workzone and Ferrex brands available to buy.

The problem with this is you can’t just pop to Aldi anytime to pick up the random orbit sander you want, instead you have to wait for it to reappear, and pick it up before they sell out. This has improved somewhat recently with the introduction of their e-commerce store, which lets you pre-order items, and tends to have stock for longer than the brick and mortar stores, but this also operates on the principle of when it’s gone, it’s gone, so if you miss it, you’ll need to wait until they feature it again.

There’s also no grantee that the drill they’re selling next week is the same one they sold last year, because Workzone and Ferrex are what’s know as private (or phantom) brands. These are brands owned not by a manufacturer or producer but by a retailer or supplier who gets its goods made by a contract manufacturer under its own label. As such, The Ferrex power screwdriver you purchased last week was likely manufactured by an entirely different company to the table saw you’re going to buy next week.

Often times it’s easy to see who the manufacturer of a product is (it will sometimes have this information available in the small print on the box), and other times it’s obvious who it might be, so you’re able to do a direct price comparison, and check the reviews of the product on sites like Amazon before you part with your cash.

But, are Workzone and Ferrex tools any good? In my opinion, the answer is yes.

As a new maker with limited budget, I’ve purchased my fair share of tools from Aldi (13 at last count, as you can see from my tools list), and so far I’ve only had a problem with one of them.

The tool in question was a Ferrex band saw, with the problem relating to the saw blade refusing to stay in place, and slipping off as soon as it started to turn. So far as I can tell, I was simply unfortunate, as I have used someone else’s Aldi band saw (which worked perfectly), and around nine-out-of-ten reviews on their own site were positive, so I guess I just got a dodgy one.

But not to fear, because in addition to their 3 year warranty, they offer a 30 day money back guarantee, and had no problem immediately refunding my money. I would have ordered another one with the refund, but seeing as I’d purchased it with money I didn’t really have, I decided I’d wait until next year.

Now, please understand that a £30 drill from Aldi isn’t going to compare with a £300 one from a brand like DeWalt. But they’re not really aimed at the same people, and for someone like me, who is a weekend woodworker and DIYer, I’m very happy to recommend Aldi’s Workzone and Ferrex products.

November 10, 2019

If you’re in a purely software business, your constraining resource is often (not always, not even necessarily in most cases, but often) the rate at which software gets changed. Well, specifically, the rate at which software gets changed in a direction your customers or potential customers are interested in. This means that the limiting factor on growth is likely to be rate at which you can add features or fixes that attract new customers, or maintain old customers.

It’s common to see business where this constraint is not understood throughout management, particularly manifesting in sales. In a business to business context, symptoms include:

  • sales teams close deals with promises of features that don’t exist, and can’t exist soon.
  • there’s no time to fix bugs or otherwise clean up because of the new feature backlog.
  • new features get added to the backlog based on the size of the requesting customer, not the cost/benefit of the customer.
  • the product roadmap is “what we said we’d have, to whom, by when”, not “what we will have”.

As Eliyahu Goldratt says, you have to subordinate the whole process to the constraint. That means incentivising people to sell something a lot like what you have now, over selling a bigger number of things you don’t have now and won’t have soon.

November 08, 2019

Reading List 242 by Bruce Lawson (@brucel)

What I’ve Been Doing

Having had time to settle in to my new job, it’s become more apparent by the day that it was a good move. I have spent a lot of time enjoying the new set of challenges provided by my job, and being part of a robust code review culture does wonders for keeping you on your best behaviour. It also polishes your ego on the occasions where people don’t find much fault with your work, which I am striving to increase the frequency of.

What I’m Doing Now

I’ve enjoyed the opportunity to get a firmer grasp of AWS services beyond EC2. I’ve particularly enjoyed getting to grips with kubernetes, as my previous ops experience mostly extended to SSH and hope. I’m aiming to pursue some AWS certifications to show off the cool new stuff I’m picking up. Does that let me put letters after my name? It had better.


November 07, 2019

Immutable changes by Graham Lee

The Fixed-Term Parliaments Act was supposed to bring about a culture change in the parliament and politics of the United Kingdom. Moving for the second reading of the bill that became this Act, Nick Clegg (then deputy prime minister, now member for Facebook Central) summarized that culture shift.

The Bill has a single, clear purpose: to introduce fixed-term Parliaments to the United Kingdom to remove the right of a Prime Minister to seek the Dissolution of Parliament for pure political gain. This simple constitutional innovation will none the less have a profound effect because for the first time in our history the timing of general elections will not be a plaything of Governments. There will be no more feverish speculation over the date of the next election, distracting politicians from getting on with running the country. Instead everyone will know how long a Parliament can be expected to last, bringing much greater stability to our political system. Crucially, if, for some reason, there is a need for Parliament to dissolve early, that will be up to the House of Commons to decide. Everyone knows the damage that is done when a Prime Minister dithers and hesitates over the election date, keeping the country guessing. We were subjected to that pantomime in 2007. All that happens is that the political parties end up in perpetual campaign mode, making it very difficult for Parliament to function effectively. The only way to stop that ever happening again is by the reforms contained in the Bill.

As we hammer out the detail of these reforms, I hope that we are all able to keep sight of the considerable consensus that already exists on the introduction of fixed-term Parliaments. They were in my party’s manifesto, they have been in Labour party manifestos since 1992, and although this was not an explicit Conservative election pledge, the Conservative manifesto did include a commitment to making the use of the royal prerogative subject to greater democratic control, ensuring that Parliament is properly involved in all big, national decisions—and there are few as big as the lifetime of Parliament and the frequency of general elections.

When a parliament is convened, the date of the next general election automatically gets scheduled for the first Thursday in May, five years out. The Commons could vote, with a qualified majority, to hold an election earlier, or an election would automatically be triggered if the government lost a no-confidence vote, but the prime minister cannot unilaterally declare an election date to suit their popularity with the franchise.

Observed behaviour shows that the Act has been followed to the letter, up to the current dissolution which required a specific change to the rules. Has the spirit of the Act, the motivation presented above, survived intact? The dates of elections since the Act passed were:

  • 7 May 2015, the first Thursday in May at the end of a five-ish-year Parliament, chosen to bring the existing behaviour into sync with the planned behaviour.
  • 8 June 2017, after a qualified majority vote within the terms of the Act.
  • 12 December 2019, after the aforementioned Early Parliamentary General Election Act.

The reason for the disparity is that the intended goal—a predictable release schedule that makes it easier for everyone involved to prepare—doesn’t match the cultural drivers. The desire to release when we’re ready, and have the features that we want to see, remains immutable, and means that even though we’ve adopted the new rules, we aren’t really playing by them.

I was tempted to hit “publish” at this point and leave the software engineering analogy unspoken. I powered on: here are a few examples I’ve seen where the rule changes have been imposed but the cultural support for the new rules hasn’t been nurtured.

  • Regular releases, but the release is “internal only” or completely unreleased until all of the planned features are ready;
  • Short sprints, where everything that has gone from development into QA is declared “done”;
  • Sprint commitments, where the team also describe “stretch goals” that are expected to be delivered;
  • Sustainable pace, where the “velocity” is expected to increase monotonically;
  • Self-organizing teams, where the manager feeds back on everybody’s status update at the daily stand-up;
  • Continuous integration, where the team can disable or skip tests that fail.

All of these can be achieved without the attached sabotage, but that requires more radical changes than adding a practice to the team’s menu. Radical, because you have to go to the root of why you’re doing what you do. Ask what you’re even trying to achieve by having a software team working on your software, then compare how well your existing practice and your proposed practice support that value. If the proposed practice is better, then adopt it, but there’s going to be a transition period where you continually explain why you’re adopting it, show the results, and (constructively, politely, and firmly) guide people toward acceptance of and commitment to the new practice. Otherwise you end up with a new fixed-term parliament starting whenever people feel like it.

November 05, 2019

On exploding boilers by Graham Lee

Throughout our history, it has always been standardisation of components that has enabled creations of greater complexity.

This quote, from Simon Wardley’s finding a path, reminded me of the software industry’s relationship with interchangeable parts.

Brad Cox, in both Object-Oriented Programming: an Evolutionary Approach and Superdistribution, used physical manufacturing analogies (to integrated circuits, and to rifles) to invoke the concept of a “software industrial revolution” that would allow end users to assemble off-the-shelf parts to solve their problems. His “software ICs” built on ideas expressed at least as early as 1968 by Doug McIlroy. Joe Armstrong talked about a universal function registry, so that if someone writes sin/1 everybody else can use it.

Of course we have a lot of reusable components in software engineering now, and we can thank the Free Software movement at least as much as any paradigm of organising programming instructions. CTAN, CPAN, and later repositories act as the “component catalogues” that Cox discussed. If you want to make a computer do something, you can probably find an npm module or a Ruby gem that does most of the work for you. The vast majority of such components have free licenses, it’s rare to pay for a reusable component.

The extent to which they’re “standard parts”, on the model of interchangeable nuts and bolts or integrated circuits, is debatable. Let’s say that you download a package from the NPM. We know that you use it by calling require (or maybe import)…but what does that give you? An object? A constructor? A regular function? Does it run anything as a result of calling require? Does it work in your node/ionic/electron/etc. context? Is it even a lump of regular javascript, or is it a Real, or to have access to a JVM, or some other niche requirement?

Whatever these “standard parts” and however they’re used, you’re probably still doing a bunch of coding. These parts will do computery stuff, or maybe generic behaviour like authentication, date UIs, left-padding strings and the like. Usually we still have to develop ours apps as “engineered” software projects with significant levels of custom coding, to make those “standard parts” actually solve a useful problem. There are still people working for retail companies maintaining online store applications across the four corners of the globe, despite the fact that globes don’t have corners, these things all work the same way, and the risks associated with getting them wrong are significant.

Perhaps this is because software is a distinct thing, and we can never treat it like industrial product manufacturing.

Perhaps this is because our ambition always runs out ahead of our capability. Whatever we can reproducibly build, we’d like to be building something greater.

Perhaps this is because we’re still in the cottage industry stage, where we don’t yet know whether or how to standardise the parts, and occasionally the boilers explode.

November 01, 2019

Reading List 241 by Bruce Lawson (@brucel)

October 31, 2019

Sprouts by Graham Lee

Having discussed reasons for change with a colleague on my team, we came up with the sprouts of change. Good software is antifragile in the face of changing:

  • Situation
  • People
  • Requirements
  • Organisation
  • Understanding
  • Technology
  • Society

Like any good acronym, it’s really tenuous.

October 30, 2019

Change by Graham Lee

I was just discussing software architecture and next steps with a team building a tool to help analyse MRI images of brains. Most of the questions we asked explored ways to proceed by focussing on change:

  • what if the budget for that commercial component shows up? How would that change the system?
  • what if you find this data source isn’t good enough? How would you find that out?
  • which of these capabilities does the customer find most important? When will they change their minds?

that sort of thing.

We have all sorts of words for planning for, and mitigating the risk of, changes in low-level software design. In fact a book on building maintainable software talks about nothing else, because maintainable software is antifragile software.

But it happened that I wasn’t reading that book at the time, I was reading about high-level design and software architecture. The guide I was reading talked a lot about capturing the requirements and constraints in your software architecture, and this is all important stuff. If someone’s paying for your thing, you need to ensure it can do the things they’re paying for it to do. After all, they’re probably paying to be able to do the things that your software lets them do; they aren’t paying to have some software. Software isn’t real.

However, most of the reason your development will slow down once you’ve got that first version out of the door is that the world (which might be real) changes in ways that it’s hard to adapt your software to. Most of the reason you’re not adding new features is that you’re fixing bugs, i.e. changing the behaviour of the software from one that matches the flawed conception you had of what it should do to one that matches the flawed conception you now have of what it should do.

A good architecture should identify, localise, and separate sources of change in the software system. And then it should probably do whatever you think the customers think they want.

October 28, 2019

With the rise of critical writing like Bertand Meyer’s Agile! The Good, the Hype, and the Ugly, Daniel Mezick’s Agile-Industrial Complex, and my own Fragile Manifesto, it’s easy to conclude the this Agile thing is getting tired. We’re comfortable enough now with the values and principles of the manifesto that, even if software has exited the perennial crisis, we still have problems, we’re willing to criticise our elders and betters rather than our own practices.

It’s perhaps hard to see from this distance, but the manifesto for Agile Software Development was revolutionary when it was published. Not, perhaps, among the people who had been “doing it and helping others to do it”.

Nor, indeed, would it have been seen as revolutionary to the people who were supposed to read it at the time. Of course we value working software over comprehensive documentation. Our three-stage signoff process for the functional specification before you even start writing any software is because we want working software. We need to control the software process so that non-working software doesn’t get made. Yes, of course working software is the primary measure of progress. The fact that we don’t know whether we have any working software until two thirds of the project duration is passed is just how good management works.

At one point, quite a few years after the manifesto was published and before everybody used the A-word to mean “the thing we do”, I worked at a company with a very Roycean waterfall process. The senior engineering management came from a hardware engineering background, where that approach to project management was popular and successful (and maybe helpful, but I’m not a hardware engineer). To those managers, Agile was an invitation for the inmates to take over the asylum.

Developers are notoriously fickle and hard to manage, and you want them to create their own self-organising team? Sounds like anarchy! We understand that you want to release a working increment every two to four weeks with a preference toward the shorter duration, but doesn’t that mean senior managers will spend their entire lives reviewing and signing off on functional specifications and test plans?

The managers who were open to new ideas were considering the Rational Unified Process, which by that time could be defined as Agile for the “nobody ever got fired for buying an IBM” crowd:

The Rational Unified Process. Image: wikimedia

That software engineering department now has different management and is Agile. They have releases at least every month (they already released daily, though those releases were of minimal scope). They respond to change rather than follow a plan (they already did this, though through hefty “change control” procedures). They meet daily to discuss progress (they already did this).

But, importantly, they do the things they do because it helps them release software, not because it helps them hit project milestones. The revolution really did land there.

October 24, 2019

In one part of the book Zen and the Art of Motorcycle Maintenance, which is neither about Zen nor motorcycle maintenance, there are two motorcycles and two riders. John Sutherland is a romanticist who appreciates the external qualities of his motorcycle: its aesthetics, and its use as a vehicle. The narrator is a classicist who appreciates the internal qualities of his motorcycle: its workings, parts, and mechanisms. When Sutherland has a problem with his bike he takes it to a mechanic. When the narrator does, he rationalises about the problem and attempts to discover a solution.

The book, which as its subtitle gives away is “an inquiry into values”, then follows the narrator’s exploration of a third way of considering quality that marries the romantic and classical notions holistically.

Now we come onto software. Software doesn’t exist. At some level, its abstractions and mathematics get translated into a sequence of states of an electronic machine that turns logic into procedure: but even that is a description that’s a few degrees abstracted from what software and computers really do.

Nonetheless, software has external and internal qualities. It has aesthetics and utility, and can be assessed romantically. A decidedly pedestrian word to describe the romanticist view of software is “requirements”, but it’s a common word in software engineering that means the right thing.

Software also has workings, parts, and mechanics. Words from software engineering to describe the classical view of software include architecture, design, clean code, SOLID…

…there are many more of these words! Unsurprisingly, the people who build software and who change software tend to take a classical view of the software, and have a lot more words to describe its internal qualities than its external qualities.

Typically, the people who are paying for software are interested in the romantic view. They want it to work to achieve some goal, and want someone else (us!) to care about what makes it work. Perhaps that’s why so many software teams phrase their requirements as “As a romantic, I want to task so that I can goal.”

Which is to say that making software professionally involves subordinating classical interpretations of quality to romantic interpretations. Which is not to say that a purely-classical viewpoint is unvaluable. It’s just a different thing from teaching a computer somersaults for a paying audience.

And maybe that subordination of our classical view to the customer/gold owner’s romantic view is the source of the principles:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.


Working software is the primary measure of progress.

In fact, this second one is not quite true. It suggests that you could somehow “count software”, and the more (working) software you’ve delivered, the better you’re doing. In fact, romanticism shows us that people only want software in that it enables some process or business opportunity, or makes it more efficient, or reduces errors, or lets them enjoy some downtime, or helps them achieve some other goal. So really progress toward that goal is the primary measure of progress, and working software is a leading metric that we hope tells us how we’re working toward that goal.

So all of those code quality and software architecture things are in support of the external view of the software, which is itself in support of some other, probably non-software-related, goal. And that’s why the cleanliness, or architectural niceness, or whatever classical quality, of the code is not absolute, but depends on how those qualities support the romantic qualities of the code.

Real life comes at you fast, though. When you’re working on version 1, you want to do as little work, as quickly as possible, to get to the point where you can validate that there are enough customers who derive enough value to make the product worthwhile. But by the time you come to work on version 1.0.1, you wish you’d taken the time to make version 1 maintainable and easy to change. Most subsequent versions are a little from column A and a little from column B, as you try new things and iterate on the things that worked.

As fast as possible, but no faster, I guess.

October 18, 2019

Save time writing release notes!

Why are release notes important?

Here at Talis, we use release notes to communicate changes to the rest of the business. They consist of a high-level overview of the changes made, along with links to Github issues where the reader can find more details should they require it. They also contain data that can be important operationally, such as the date we deployed the release and the build number that generated the artifact. This small piece of information is vital should a bug be discovered in production and we need to trace it back to a specific change.

For example, let’s say we refactored part of our codebase, then a month later we discovered some documents were missing attributes. When the discovery is made that we are missing attributes on documents, we can find the earliest document that is missing attributes and then immediately find releases around that time. From there we can easily debug the cause of the problem, and then work on a fix as well as fixing all documents since that release.

Save time writing release notes!

As important as release notes are, don’t waste your time writing them. The process can easily be automated! For years we have had a bash script that would generate release notes. This bash script would go through all the commits since the last release and then output some markdown for you to copy and paste into the Github release. As you can imagine, it wasn’t much fun running a bash script to then copy and paste the output into Github. But it did the job we needed it to do.

Moving to Release Drafter

One of our developers, Ben, spent his personal development time (here at Talis, developers can spend half a day a week learning new technologies or anything unrelated to their current theme of work) investigating better ways to automate the creation of our release notes and subsequently gave a talk to the rest of the development team about Release Drafter. The main idea behind Release Drafter is that it will create a draft release with all the changes in master since you last published a release, you can also categorise the contents based on the tags added to the pull request. Then when you come to releasing you just add the tag and the title, then hit the publish button.

Shortly after the talk, we began trialling Release Drafter on several repositories with a custom configuration. The standout feature for us was the ability to parse commit messages with replacers. This meant we could extract data from commit messages to provide links to issues. After a week or so of trialling Release Drafter, we made the decision to roll it out across all our repositories. To do this with a custom configuration we created a .github repo in the organisation and added our config to .github/release-drafter.yml as per the documentation. We then installed Release Drafter as an app for the organisation and enabled it for the majority of our repositories.

So with a simple configuration our release notes are now generated automatically. This does require that commits start with ISSUE-<issue_number> to correctly link back to the issue within Github.

_extends: .github
name-template: Release <TAG> on YYYY-MM-DD
  - search: '/ISSUE-(\d+)/gi'
    replace: '[ISSUE-$1]($1)'
  - title: 'Features'
    label: 'feature'
  - title: 'Bug Fixes'
    label: 'bug'
template: |


Now our process for creating release notes has been simplified, from manually copying the output of a bash script, to editing a precompiled release draft - not a single developer misses the trusty old bash script we used to run. Thanks to the team at Release Drafter for helping to make our workflow that little bit easier.

October 16, 2019

A question of focus by Graham Lee

The problem with The Labrary is that I offer to do so many things – because I could do them, and do them well – that it can be hard to find the one thing I could do for you that would be most helpful:

  • Artificial Intelligence
  • Agile Development
  • Continuous Delivery
  • Software Architecture
  • Technical Writing
  • Developer Experience
  • Programmer Mentoring

Each of these supports the mission of “making it faster and easier to make high-quality software that respects privacy and freedom”, but all of them is overwhelming. I have credentials/experience to back up each of them, but probably don’t have the reputation as a general expert that someone like Dan North or Liz Keogh can use to have people ask me anything.

So I want to pick one. One thing, probably from that list, and pivot to focus on that. Or at least get in through the door that way, then have the conversations about the other things once you know how much faster and easier I make it for you to make high-quality software.

And I’d really value your suggestions. Which one thing do you know me for, above all others? Which one thing is the pain that the place you work, or places you’ve worked, most need fixing?

Comment here, have a chat, send an email. Thanks for helping me find out what I want to be when I grow up.

October 11, 2019

Reading List 240 by Bruce Lawson (@brucel)

Hello, you kawaii kumquat! Here’s this week’s lovely list ‘o’ links for your reading pleasure. It’s been a while because I’ve been gallivanting around Japan, Romania and the Netherlands, so this is a bumper edition.

There won’t be a reading list next week as I’m going off the grid to read books and record music in a 400 year old farmhouse in the countryside, far from WiFi and the bleeps and bloops of notifications. Until next time, hang loose and stay groovy.

Back to Top