AfterwoodWhen I think of some of the most memorable comedy acts, I instinctively go for the partnerships, such as Laurel & Hardy, Morecambe & Wise, The Two Ronnies, and The Chuckle Brothers. Okay, maybe that last suggestion isn’t in my top 10 but they do spring to mind very quickly because they are another famous comedy partnership.
Does this mean that the best comedy only comes from partnerships? If I try and think of specific comedians then I’d possibly go with Bob Monkhouse, Steven Wright, Jimmy Carr or Jack Dee. Of course the face of the comedy act, the end product if you like, is the performance, the eventual delivery of the stream of gags from script to audience. What we might perceive as being a solo act, duo or group may just be the chosen form of delivery; behind the scenes the people that produce the actual content – the writers – may well be comprised of an entirely different number.
If you’re bored enough to watch the credits at the end of a TV show, you’ll often find there is more than one writer listed. Even if they acknowledge some writers under the separate heading of ‘additional content’, you’re still likely to find the lion’s share of the writing attributed to more than a single person. It’s not uncommon for one half of a writing duo to be the most prominent face (e.g. Bob Monkhouse and Ricky Gervais), whereas the other half remains less well known because they are only supporting players in the performance (e.g. Denis Goodwin and Steven Merchant). Naturally, it doesn’t stop at two, there are bigger teams of writers as well, but the point is that writing (and clearly not just in the field of comedy either) is commonly seen as a highly collaborative profession that benefits greatly from the input of many sources.
So why is writing software, which is also largely about communication, still often perceived as being a solo activity? Has the word of Eliyahu Goldratt [Goldratt84] (or more recently Kim, Behr & Spafford [Kim13]) about focusing on product flow instead of programmer utilisation still not reached in to the heart of the software industry’s extensive management culture? Or is it ourselves, the legions of programmers, that are reluctant to give up our cubicles for fear of losing our identity?
In the past year I have done very little programming by myself. The vast majority of my time has been working in a pair, but I have also had the pleasure of doing a significant amount of mob programming too, usually in a group of four. I’m reaching a point now where the thought of having to work by myself makes me feel uncomfortable because I don’t want to suffer the loss in productivity. It’s still nice to do some background learning in the comfort of my own space but when it comes to delivering product features where the focus is on delivering working code to the customer, the joint effort is now feeling like a more natural way to go.
The reason it’s taken so long (for me) to see the light has almost certainly been of my own making. Back when the ACCU conference was hosted in Oxford I remember a late night conversation in the bar (of course) where I posed the question about how the productivity of experienced programmers would benefit from practices like pair programming. The mistake I made back then was to think of two programmers as two CPUs sharing a problem – each additional CPU only adds another 60% (historically) due to communication overhead. But reading The Goal (and more recently The Phoenix Project) I realised my mistake was to think of myself as a resource to be utilised to 100% capacity, rather than leveraged to minimise the time to market of features (and therefore maximise the value extracted from each proposition).
Whilst I had always felt that being able to help unblock other people at the cost of not delivering as much personally was the right thing to do (a global optimisation) the management focus around individual performance always made it a choice which I was ill equipped to explain. Luckily books like Laurie William’s Pair Programming Illuminated is becoming more well-known and has concrete data to back up the anecdotal evidence which has been floating around for much longer. This book, along with a number of other sources, came to my attention via talks given by Jon Jagger [Jagger16] and they have in turn been passed on to some of my clients that have also been sceptical of the practice. Their scepticism, like my own though, is usually borne out of looking for the answer to the wrong question.
As I suspect is the case with traditional writing partnerships, some work much better than others. Being a couple of decades into my professional programming career, I can’t know how it would pan out for more junior developers but pairing and mobbing with experienced developers has mostly worked out extremely well. It’s entirely possible that being mature freelancers, we’re not worried about climbing the greasy pole and so we’re entirely comfortable with just getting on with the task at hand and don’t assume that any criticism is intended as a personal attack. We all have different backgrounds and that is something to be embraced, not diluted.
Programming in a group of two or more is definitely a skill in its own right. Just as with any conversation knowing when to speak and when to be silent is something you have to learn. Similarly if you currently have the keyboard you’ll probably be bombarded with ‘advice’ and you’ll need to learn to mediate. There are likely many things you’ll want to pick up in the early days of your relationship, such as better ways to use the tooling and express concepts in code, and that’s all on top of working together to solve the actual problem at hand, which should always be the primary focus. Personally I find the small scale scope creep trap all too easy to fall into and really appreciate having ‘Gold Five’ constantly reminding me in my ear to ‘stay on target’.
One day I hope the software tooling world will catch up and each commit can read like the credits at the end of a TV show or film where all those who contributed to the feature are rightfully acknowledged, instead of just the one programmer who got to execute the final commit and push. And it’s not just the programmers’ names either; if you work in a cross-functional team you may well have a BA and QA providing valuable insights and direction which means your commit should be attributed to The Three Amigos.
The world of software is still dominated by the names of individuals, such as Linus Torvalds, Larry Wall and David Heinemeier Hansson. I wonder if in the future, when more of us start to work more closely with our fellow colleagues, we’ll see a rise in the kind of partnerships that roll off the tongue, like Kernighan & Richie or Pike & Thompson?
References
[1] The Goal - Eliyahu M. Goldratt (1984)
[Jagger16] http://jonjagger.blogspot.co.uk/2016/04/pair-programming-keynote.html
[Kim13] The Phoenix Project Gene Kim, Kevin Behr, George Spafford (2013)