How to write software like The Beatles wrote music
04 November 2019
This article examines the Ying-Yang dynamic that made Lennon-McCartney a tour de force in the world of songwriting and advises how the same method can be applied to designing software.
You may have noticed that Abbey Road, The Beatles’ eleventh studio album, has recently made a resurgence in the charts due to its re-release in time for the 50th anniversary of its original release last month. With a mixture of blues, pop and progressive rock alongside The Beatles’ traditional rock and roll musical style, the album is one of their most critically acclaimed, selling over four million copies in its first two months of release.
In accordance with the rest of the band’s oeuvre, the composition for the majority of tracks is attributed to ‘Lennon-McCartney’ (or vice versa), with credit never solely given to either one of the duo. As many close to the pair observed, Lennon and McCartney’s relationship was characterised by collaboration and competition, the Ying to the other’s Yang: According to Cynthia Lennon, “John needed Paul’s persistence and attention to detail. Paul needed John’s anarchic, lateral thinking.”
The binary relationship between Lennon and McCartney allowed the raw talent of both to be controlled, filtered and refined, ultimately creating a dynamic and versatility which fed the band’s success. Just compare how the original demo version of Lennon’s ‘Help!’ had its raw emotion channelled by McCartney into something slightly less moody and more resonant in the final studio version. By bouncing ideas of each other, taking new ideas and influences and channelling them through each other, Lennon and McCartney became pioneers of musical innovation.
Getting by with a little help from a friend
‘Lennon-McCartey’ has now become a by-word for pairs coming together to create something greater than the sum of their parts. In business, where this phenomenon is more commonly known as ‘co-opetition,’ combining elements of competitiveness and collaboration similarly helps to navigate through fragments of ideas, resolve confounding issues and cultivate inspiration by simply working together to achieve a common goal.
In the world of software development, co-opetition takes the form of ‘pair programming.’ With two keyboards, two mice, two monitors but only one computer, pair programming allows two developers to work on a single piece of software simultaneously with the goal of producing higher quality, more maintainable software, faster.
Typically during pair programming, one developer takes the role of the ‘driver,’ while the other take the role of the ‘navigator’: the driver – manning the accelerator, brake pedals and the clutch – actively types lines of code, deploying the best of his or her content knowledge in writing the program; while on the other hand, the navigator – tasked with reading map directions, checking wind speed/engine lights and alerting the driver of impending turns, dips and inclines – checks errors, looks up APIs, probes and questions the code, asking “why are things are done that way?” These roles should be flipped throughout a session of code-writing every so often to make sure that the work produced is constantly refreshed, re-interrogated and re-evaluated.
There's no time for fussing and fighting, my friend
Pair programming works by mitigating one-upmanship with empathy. Competition is great for spurring individuals to produce a flurry of ideas which, to them may seem great, but for others (i.e. end users) may seem unrefined and do not resonate with the intended objectives. By working together, an initial testing phase occurs implicitly during the early stages of the creative process. A driver writing code under the watchful eye of the navigator will ask themselves, “this looks good to me, but how does it look to them?” This helps to ensure that the core values of empathy, communication and trust that are crucial to making software resonate with end users are also implicit components of the process of software development.
The benefits of pair programming not only apply to the end-user. Just like John learned from Paul and Paul learned from John, having two individuals with a plethora of unique experiences, influences and ideas work together creatively can be a highly educational experience for both. Working in pairs helps to transfer knowledge, eradicate bad habits and develop new skills much faster than an individual could in a classroom, with a book, or on their own. This work also helps to diversify a single programmer’s area of expertise: pair a front-end engineer with a back-end engineer for a few months and you’ll see the former cranking out prepared statements and the latter working on HTML5 optimisations in no time.
Nowhere man, sitting in his nowhere land
Like writing music, writing pieces of code requires creativity. There’s a myth that inspiration comes from months of meditative solitude, but one need only read Frankenstein to realise the hubris of a design process spearheaded by a single individual laser focusing on the end product, rather than the end user. In fact, it is precisely this ‘lone wolf’ personality type that suits pair programming so well. Constantly trying to be the best in your field means trying to one-up your peers, and what better way of doing this than to take part in the creative process in alternation with them?
Assumptions aside, research into the effectiveness of pair programming speaks for itself. In a study measuring the efficacy of pair programming among 1,200 beginner-level computer science students and 300 third/fourth year software engineering students, pair programming was shown to help students learn fundamental skills on an individual level. Students in classes in which pair programming was required generally had higher project scores and higher exam scores. Most importantly, when students were then forced to work alone, the students who had pair programmed were more likely to have maintain or improve their grades than the students who had worked alone.
Innovation, collaboration, revolution
Between 1957-1970, the Lennon-McCartney song writing partnership helped The Beatles to be one of the most innovative, reactive and dynamic bands of the era, despite a transformation in musical styles and cultural upheaval. In the current era, where legacy organisations are rushing to enact digital transformation and cloud-native start-ups are fully leveraging their agility, there is a lesson to be learned here. Collaboration is key to innovation, and innovation is key to survival.