Software quality: why you shouldn’t ignore the small things

When your product to-do list (aka the product backlog) is very long, with “urgent” items or requests from your biggest or most demanding users, the natural path is to focus on the high value work.

New features that could bring in new users or retain existing ones. Major bugs. Quick wins.

Everywhere I’ve worked, and in fact in most software projects I’ve heard of, there’s always more to do than you can actually get through. You can’t do everything, so you have to prioritise what to work on next.

As part of gathering feedback from users, QAs, or your own product review cycles, you’ll sometimes identify issues or potential tweaks which, in the grand scheme of things, seem very minor. Perhaps there’s a small layout bug on iOS. A little-used setting doesn’t work for a small number of users. An old page that hardly anybody goes to doesn’t look right with a recent design overhaul. Or a page is retired and removed from the navigation links – but it’s still accessible if you visit it directly.

I’ve heard numerous excuses for not dealing with minor changes such as the above. It’s not important. We’ve got bigger fish to fry. We’re too busy. Etc. However, if you ignore all of these small issues, they can build up and collectively give users the impression that the product is being neglected.

It’s a broken window situation.

In The Pragmatic Programmer, there’s a section called Software Entropy that mentions broken windows. I’d like to highlight this quote:

Don’t leave “broken windows” (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. Perhaps you can comment out the offending code, or display a “Not Implemented” message, or substitute dummy data instead. Take some action to prevent further damage and to show that you’re on top of the situation.

If something’s broken, fix it. If it’s not used anymore, remove it. To help with this, gather feedback to see if users are finding pain points that you’re not aware of. Use analytics to see which parts of the product are being used.

Don’t ignore the minor things. While one small UX quirk might not make much difference if you fix it, lots of UX issues in the same area of the product can really annoy your users. Leaving this unresolved can make software feel awkward and frustrating to use, or just plain broken.

Is that the kind of product you want?

Music Monday: How I got into Trance

I love trance. I’ve loved it since I first heard it back in 1998. Twenty years later, here’s a quick look back at how it started for me.

A lot of the music I listened to while growing up came from my parents. My parents split before I was a year old; I lived with my mum, my brother and my sister. From quite a young age, I’d see my dad almost every weekend. I’m sure my parents played music with all of us in earshot, but I’d say that I listened to it the most closely of my siblings.

Many great albums followed. After devouring the entire discography of The Beatles and Dire Straits, plus a scattered group of albums from the likes of Mike Oldfield, Elton John, Bruce Hornsby, Status Quo, Genesis, and Pink Floyd, I was hungry for more.

It was my mum who played Jean-Michel Jarre – I don’t think it was ever a full album though, just a track or two from a compilation. Around the time I started my first part-time job and therefore earned a bit of money, I remember buying three Jarre albums: Oxygène, Oxygène 7-13, and Odyssey Through O2. I’m pretty sure I bought the first two together in late 1997 or early 1998; I spotted the third when it came out around the middle of 1998.

While I did enjoy the first two albums a great deal, it was Odyssey Through O2 that resonated with me the most. I played tracks 7-10 the most; this run of four tracks representing my first experience of a trance mix – although to be picky, track 10 is more of a breaks track. Still, this section of the album was always my favourite. I still enjoy it to this day.

(Sadly, Odyssey Through O2, isn’t on Spotify, but here’s the Oxygène Trilogy, at least.)

At this point, I was still at the stage of discovering music at the artist level. My parents had introduced me to several artists as I mentioned above, and this was an continuation of that. For now, I’d continue exploring each artist’s catalogue a bit more deeply, aiming to collect every album by many of the artists I enjoyed. However, I’d discovered something a little different with Odyssey Through O2 – something deeper than the artist-by-artist music exploration I’d been on up to that point.

Sometime in 1998, a friend was playing a CD that I recognised as being similar in style to Odyssey Through O2. Actually, it didn’t start that way, as the mix had a couple of tracks that weren’t as trancey as the rest – such as Da Hool “Meet Her At the Love Parade”. Next up was Three Drives “Greece 2000”, which was more up my street. However, the track that really did it for me was Energy 52 “Cafe Del Mar ’98”.

Bloody hell. This album was awesome!

Of course, these tracks (and others on the album) became very well-known and massively overplayed over the next few years in particular. But imagine hearing them for the first time. This was one heck of a good mix.

Incidentally, that was the Paul Oakenfold mix of Essential Selection ’98 – guess what, that’s not on Spotify either. Dance compilations are the primary reason I haven’t completely moved away from CDs, much as I would like to. Anyway…


Once I’d figured out that I wanted to find more trance music, I asked my siblings (yes, them again!) as we shopped in HMV one day. We scanned through several compilations; I’d already picked up Essential Selection ’98, but wanted to get one more CD. I think my sister picked up an album, pointed to Binary Finary “1998” and said that was a good track; admittedly, we didn’t recognise the other tracks, but I took a chance and picked it up.

That album turned out to be Reactivate 13, which led to a long and somewhat obsessive relationship with pretty much anything on the React label. My 19-20 year old self made a prat of himself by flooding the React online forums with endless posts (and I rather stupidly used my real name); I think a few people there thought I was a bit of an idiot. But hey, the music’s what it’s all about, and I still have Reactivate 9, 10, and 12-18.

Here’s a playlist of my personal favourites mostly from Reactivate 12-17, with a couple from earlier volumes.

I was never a massive London clubber, but I did go to a few clubs, especially during trance’s heyday. I distinctly remember hearing several of my favourite trance anthems in either 1998 or 1999 at Camden Palace. And I could just about deal with the long, sweaty night, getting gradually more tired – not to mention hungry – as 6:00am approached, with the club drawing to a close, and the first trains starting to run in the morning. However, I was less keen on the volume of the music, and the ringing in my ears for the next 24 hours. On my first visit to a London club, the pounding in my ears was so intense, I felt like I was going to throw up within the first five minutes.

Despite that, London clubbing when trance was big was absolutely incredible.

I may be 20 years older, and I may not listen to trance as much these days, but I still love it. Maybe one day I’ll go back and do it all over again.

Music Monday: The Tibbs – Takin’ Over

A lot of my recent favourite tracks come from Spotify’s “Discover Weekly” playlist, or one of a few other Spotify playlists that I keep an eye on and plough through whenever I’m in the mood for something new. This is how I discovered The Tibbs; the entry point being the track “Lies”, which I’d strongly recommend checking out.

Such is the nature of Spotify, I added the track to one of my own playlists, listening to it whenever it came up. With hundreds of tracks across a handful of lists, I don’t always check out an artist’s other tracks. However, on this occasion, I found myself listening to “Lies” so many times, I felt I had to venture further into the Spotify rabbit hole. I soon came across the album “Takin’ Over”.

It’s fresh, with mostly upbeat, funky tracks that are a joy to listen to. Current favourites include “Dog Days”, “96 Tears”, “Washed My Hands”, and “Cussin’, Cryin’ & Carryin’ On”, to name a few.

The whole album is sublime, and well worth listening through in its entirety (all 39 minutes of it).

As it turns out, I’m an idiot, because I could’ve discovered some of the band’s catalogue a couple of years sooner. I previously bought “Footprints in the Sand” following a recommendation from Juno Download – probably the “Recommends” section of the Funk genre. That’s worth a listen too, so I’ll leave you with that track too.

Use Makefiles to quickly run common commands

A tip I picked up from work is the use of a Makefile to set up short aliases for commands you run often, but that are a pain to type, or you can’t remember. I find this particularly useful as I code fairly intermittently these days, so it’s easy to forget the exact syntax of certain commands.

A good example is how to run unit tests. This varies from project to project, but is something you’ll probably want to do fairly often.

To start, create a blank file called “Makefile” and put it at the root of your project. Then insert the following code:



Change /bin/bash to the location of Bash, and modify the ./vendor/bin/phpunit line to do whatever you’d normally type in to run your unit tests.

You’ll need to replace [TAB] with a Tab character. Spaces won’t work. Make is strict in this regard.

Save and exit the file. Now open a Terminal, go to the root of your project, and type:

$ make unit-test

All being well, this will run your unit tests.

In the Makefile, “unit-test:” indicates the label you’ll need to run after “make” to run the command. You can add multiple lines and multiple labels – for instance:

[TAB]echo 'A'
[TAB]echo 'B'

[TAB]echo 'C'
[TAB]echo 'D'

If you have lots of commands, this method can get a bit messy. It’s handy for small projects where you only have a few things to include but can’t always remember them.

FAWM 2018: a good excuse to write new music

Last year, I wrote 16 tracks as part of FAWM, an annual songwriting challenge where the goal is to write 14 tracks in 28 days.

This year, I’m a couple of days late posting my first tracks (compared to last year, anyway), but I’ve made a start. Here’s my FAWM profile with links to the new tracks.

I was really pleased with the tracks I wrote last year, which I used for a new album – “Ten“. That album is exactly as it was once FAWM 2017 ended. I didn’t add or remove any tracks, reorder the sequence, or edit any of the music.

When I got started this year, I was a bit rusty. It took a few tries to come up with the first track (Synthrock), which I wasn’t completely happy with – but with a time-based challenge, there isn’t a lot of time to procrastinate. So I thought it best to finish the first track, and get on with the show. I’m happier with the second track (Psionetrics) and this should help keep my motivation up.

I find that FAWM is a great way to write new music – I only wish I hadn’t had ten years away (between 2007-2017).

On becoming a Scrum Master

I got my first job in tech back in December 1998. In my career so far, I’ve worked in pure coding roles, I’ve worked as a tester, and I’ve had a couple of more varied roles.

A few years back, I was working long hours for an extended period of time, and I completely burned out. While I continued coding so as not to lose the skill, it quickly became something I no longer enjoyed doing.

This year, I came to realise that my coding days are coming to an end. I’ve fought it for some time, but I’ve recently come to accept it. I’ve also had the opportunity to move into a Scrum Master role at my current workplace, which has helped a lot.

My new role has made me realise that while I may have enjoyed coding in the past, the thing I enjoy most – and that I’m good at – is delivery, aka getting shit done.

Being a Scrum Master, a Delivery Manager, an Agile PM or whatever I might call myself today or in the future, isn’t my only skill – but it is what I’m particularly good at.

I don’t know if I’ll be blogging about delivery a lot, a little, or at all. I don’t blog particularly often these days. But that’s mostly due to a lack of focus on my part. I like to do a lot of different things. As a result, I can’t focus on being the best at anything.

I’m far from the best coder. But I was always good at getting shit done. When I look at my past jobs, I don’t want to shout about what tech I used, how I solved complex problems, or how I designed my solutions. I’m far more interested in what I delivered – and the fact I got the job done – than how I did it.

I’ve worked with some amazing developers in my career. Many of those developers are great at getting things done. Some consider technology options at length, and maybe are hesitant to make a decision in case it’s the wrong one. Some may obsess over doing things perfectly. There’s definitely a place for planning rather than jumping straight in and making a mess of things. However, it can be taken too far.

Anyway, delivery is what I do. It’s what makes me tick. It’s the area I can help with the most.

And I’m glad to have finally figured this out. It only took me 19 years.