We can work it out: How the Lennon-McCartney partnership can translate to software development

At the beginning of October Abbey Road, The Beatles’ last studio record – though penultimate release – regained the number one spot in the UK charts thanks to the release of a special 50th anniversary edition.

As with the rest of the band’s oeuvre, the composition credit for the majority of tracks was attributed to ‘Lennon-McCartney’, rather than one of the duo. While by the time of Abbey Road’s release virtually all of the songs were written individually, earlier compositions saw plenty of collaboration, fuelled by the two’s relationship with each other. According to Cynthia Lennon, John “needed Paul’s persistence and attention to detail, [while] 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 off 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-McCartney’ has now become a byword 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.

Pair programming sees one developer take the role of ‘driver’, actively typing lines of code, while the other navigates, checking errors, looking up APIs, and probing the code

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.

Baby, you're a rich man

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 frontend engineer with a backend 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?

In a study among 1200 beginner-level CS students and 300 advanced software engineering students, those in classes where pair programming was required had higher project and exam scores

Assumptions aside, research into the effectiveness of pair programming speaks for itself. In a study measuring the efficacy of pair programming among 1200 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.

You say you want a 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. 

Interested in hearing industry leaders discuss subjects like this and sharing their use-cases? Attend the co-located 5G ExpoIoT Tech Expo, Blockchain Expo, AI & Big Data Expo, and Cyber Security & Cloud Expo World Series with upcoming events in Silicon Valley, London, and Amsterdam.

Rojenx is a leading concept artist who work appears in games and publications

Check out his personal gallery here

This site uses Akismet to reduce spam. Learn how your comment data is processed.