I was recently challenged during a one-to-one with my mentor at work to write a blog about the links/parallels between software development and music. My mentor has an interest in the promotion of STEM (science, technology, engineering, arts and maths) and STEAM (which adds arts in too). I thought this was an interesting idea so I’m having a go! The first thing that pops into my head when I think about software engineering OR when I think about music is creativity…

Creativity

I think the main reason I love software engineering is the sheer creativity, we start with a defined a bunch of building blocks (a language and base class library etc) then we go about the process of solving problems or realising ideas using a limitless amount of these blocks, sometimes creating higher level reusable blocks, sometimes pulling in someone elses. With cloud scale, the only limits really are your imagination!

From my personal experience, I see a strong link between my obsession with career in software with a love of Lego as a child. I asked for Lego at every opportunity and enjoyed building the official model, but only ever once, after that I would add the pieces to my very large box and build whatever I wanted. (At college, I built a prototype of a racing car in Lego that had working accelerator, brakes, a clutch and a 3 speed gearbox and I had so much Lego that it was all colour coordinated and everything!)

What I’m not sure about is whether the Lego gave me that creativity or just gave expression to it. My son likes Lego but not in the same way I loved it. I see a similar thing with children who love Minecraft.

Anyway, back to music. Music is obviously a hugely creative thing, although slavishly learning piano pieces for an exam is certainly not fun. I learnt trumpet classically to the point where I could read music by sight fairly well, even transposing into different keys, but I was so frustrated that I couldn’t improvise to save my life! I always longed to be able to improvise! I certainly enjoyed playing music in a group where the sheet music was the key to transforming a set of individual solo efforts into something that was more than the sum of the parts. That was definitely still a creative thing, but different to creating something from scratch. Similar to building the official Lego models.

Personal software development practice and personally playing an instrument

At first, when thinking about what to write, I was looking for parallels between personal software engineering practice and personally playing a musical instrument, there are definitely some: practice, research and learning by reading etc, even going to a conference to hear a particular speaker is similar to going to your favourite band’s gig or a clinic with your favourite bass player etc. Also the concept of a music teacher is quite like that of a mentor or senior in a team who has an interest in inspiring the team members to reach their potential by passing on what they have learnt. But I was sure there must be something more compelling that those!

Comparison of a software development team and a band

I switched to considering the similarities of a software engineering team and a band and I think there is much more to learn.

Playing in a band can be one of the greatest things in life. I am going to focus on what it is that makes a great experience of playing a song in a band, when everything works and a lovely piece of music is the result. I’m thinking about a band with guitars and drums rather than say a brass band or orchestra, although I guess the same applies.

The Groove

A song will have a ‘groove’ which is a kind of rhythmic repeating pattern which is established by the drummer and bass player. The pattern will usually feature accents using the Kick and Snare which the bass player also picks up in the notes they play. The groove sets the ‘feel’ of the song and will be influenced by the style of the music and/or other songs or favourite artists. For instance, in Reggae music the groove is usually swung and places a heavy emphasis on the off beat, whereas in a rock groove it is normally played straight and there is a kick on beats 1 and 3 and a snare on 2 and 4. In western music, which is normally structured in 8 bar sections, there would probably be different grooves for different sections of a given song, one for the verses, one for choruses and another for the bridge etc. At the end of a section there would normally be some kind of fill which is where the drummer and/or bass player would play a something slightly different usually ending in a hit on a cymbal. The groove also has a tempo, which is the speed at which the song is played.

In software…

I’m not sure what the groove equates to in software? It could the technology stack chosen for the job or the agile methodology which shapes the process. There should definitely be a rhythm in a software engineering team and it should feel like everyone in the team is pulling together in one direction and with one shared aim. In the same way that groove has influences from styles or other songs or artists, the members of the team will have had past experiences of technologies or design patterns and will hopefully bring in those experiences where appropriate.

Listen to each other and work together

Probably the most important thing when playing music in a group is to listen to each other. Each person should hold the aim of creating some lovely music more highly important than say personal recognition or being so loud that they drown out everyone else. When each player listens to the others they can stay in time, stay grounded on the groove, they can leave space for each other and play things that compliment the other parts. This is what turns of bunch of separate noises into some music. Band members get to know each other well and begin to ‘play off’ each other where the idea of one person can inspire another idea in someone else. Suggesting an idea can be quite a daunting thing to do because it makes you a bit vulnerable, you need to know that the other band members will not reject ideas harshly.

In software…

I think there are striking similarities here, in a software engineering team, members should be working together and aware of what the other members are doing. They should help each other when needed and ensure that when separate streams of work are going on in parallel, the work can be integrated easily when it comes back together.

In terms of suggesting and trying out ideas, this is crucial:

suggestions, questions and contributions to discussion are not only wanted, they are absolutely needed from every member of the team! There are no stupid questions!

I suggest you drill this into each and every member of your team!

The key to working together well is communication. Team members should be able to inspire each other, to respectfully challenge each other, to show flexibility and to negotiate and compromise. You need the culture to be friendly, open and honest for this to happen. I’ve found that admitting your own mistakes, failures and weaknesses really helps with this. You want your team members to be comfortable showing vulnerability, to admit when they don’t know or understand something or to be able to say when they are just having a terrible day. Once this does start to happen, you will have a team who feels ‘safe to fail’ having the emotional security they need to have ideas, make suggestions, try things out, learn from failures knowing no-one is going to punish them etc. Most importantly they will realise that they have a voice and an important contribution to add, which will make them enjoy their job and feel fulfilled.

Dynamics

A good song feels like its going somewhere, it starts in one place and builds to another, there can be quiet sections, sections which build and louder sections.

In software…

In software engineering teams, we tend to focus on a consistently high velocity, I wonder if teams should plan quieter times or sprints with a different focus? I have heard of the concept of ‘firebreak’ sprints where the team is allowed a whole sprint where they can decide what to work on. This might be a piece of tech debt or a new concept idea or some kind of test or deployment tool etc. Even the concept of a ‘sprint’ has always seemed a bit wrong to me - as no-one can keep sprinting forever (however much business like the idea!) its a short exhausting burst. I prefer a decent paced long distance event, which might be more like Kanban, but thats probably a different post.

Practices and performances

If a band has a performance or tour coming up, they will practice and practice and practice some more. They will know their parts so well they could play them in their sleep and then when the time comes they can deliver a perfect performance to their fans.

In software…

I think this could have some relevance in the area of deployments or migrations. I’ve worked in places where deployments were practiced, but rarely in a sufficiently live-like environment to promote serious confidence. Maybe if we thought that people would be watching we would do things differently?

To sum up

I think there are a lot of interesting similarities between bands playing music and software engineering teams, some more obvious and some more subtle. There may be aspects of both which would benefit the other in some way. The analogy of course breaks after a while, take pair programming for instance, that would be very interesting in a band! Thanks for reading.