You may have discovered this already but large-screen TVs make very good tools to support pair programming. Rather than have people gather around a small screen (not very comfortable physically or on the eyes) a big screen TV lets you display the code and other stuff in a comfortable manner. I was prompted to write this after a chat with our JISC programme manager David Flanders who seemed to think it a story worth sharing (you can check out his blog at here. His post on Cory Doctorow’s ‘Makers’ is highly relevant to this theme and got me thinking a lot about working cultures for developers something that I know David is very interested in.
We stumbled on this way of working while having development sessions at Will’s flat. Will had already discovered how to hook his laptop up to the TV via the HDMI connector. He then used a wireless keyboard that allowed him to sit on the sofa while the laptop was parked next to the TV, which is a 40” Sony Bravia. This kind of arrangement turns out to be a perfect arrangement for pair and triple (and even crowd) programming. We sat on the sofa and easy chairs in the lounge while the code appeared on the screen. More than this though we were lucky that Will is also a trainer and used to ‘doing and describing’ at the same time something that can be rare or difficult for many developers. So, if you find someone in your team who can do this – treasure them, as they will be an excellent facilitator in such activites that really help team members learn rapidly . As a result, the three of us (Chris, Will and me) were sitting in comfy chairs watching the telly, calling out comments and questions or just watching as Will worked and talked us through what he was doing. It was an impressive and useful exercise that helped show how effective this way of working – can be. One thing we found was that it can be helpful for someone to act as a ‘spotter’ looking for typos and simple errors while the active coder is in action. Of course the people involved have to be comfortable with this – if they are uptight individualists who spend too much time alone coding it can be like pulling teeth! And if they are working in an environment that discourages such team behavior then this approach will be seen as very disruptive – of which more below in my note on working cultures.
Such an arrangement can be tiring for the lead coder / presenter so allow time for them to rest during a session – which can be taken up with discussions about the project, the code or, having lunch or chatting about things in general etc. This approach should also be useful for training up developers new to a project, who can just watch and learn in a very rapid way ‘on the job’. What is described here would be a perfect example of what is known as the ‘cognitive apprenticeship’ approach to learning – a well-recognized and effective method in educational and training circles check it out here on wikipedia, if you are interested in training and improving software development practice then you really should check it out. It can also be a good way of shaping and affirming the working culture you want to adopt and maintain for good development – like; open, sharing, supportive, team-work and all those nice kinds of ‘fluffy’ things that can make people happier and more productive in their work. As I go on about at some length below I believe it is these soft issues that are the key to productivity in software development, as well as other sectors.
A note on working cultures
Sitting on sofas watching big screen telly might seem a a parody of the ‘cool geek’ who hangs out in the sunshine land of techno-myth, although by no stretch of the imagination would the three of us see ourselves in that way 
. Of course it is not the only way of working or one that you might adopt all the time, but it can be very effective for reasons given above. However many workplaces in the private and public sectors would not be happy with such an approach. For those of you not familiar with these issues let me give you an example from my own experience.
A while back I worked for an organization that employed a lot of developers who worked on different projects. Work was organized so that developers on projects stayed within a project team and did not really mix or share with those on the other projects and so could not learn new skills or insights – they were confined to project ‘silos’. All the teams worked in an open-plan office where there was a ‘no-talking’ rule. If they wanted to discuss something they had to book a meeting room and do it there. Communication was restricted to a few furtive hushed whispers or formal team meetings with managers in one of the meeting rooms.
This was not a working environment that the words ‘creativity’, ‘serendipity’, ‘insight’ or ‘fun’ could be applied to. You will get no prizes for guessing that this place was a miserable outfit to work in but it might also surprise you that the output and efficiency of the organization was abysmal, measured on any scale. The project still lives on as a kind of ‘zombie’ project one of many, unfortunately, in the public sector.
Despite the management running such a ‘discipline and punish’ regime (to borrow a phrase form Michel Foucault) , it did not result in greater productivity – quite the reverse. Unfortunately, this is far from being a rare situation and it sums up many of the deeper contradictions at the heart of the organisation of this kind of modern cognitive workplace.
As the writer Cory Doctorow writes in his book ‘Makers’ (read it online here) one of the strange things about the times we are living in is that we live in an era of great and growing abundance in terms of available resources to create good software. Yet, when we come to work together managers (and some developers) seem to be determined perpetuate a culture designed to produce scarcity, as in my work example above. Oddly enough two left-wing philosophers have a useful and productive observation to about this contradiction in software development and it is in relation to what may be termed ‘The Common’. Michael Hardt and Toni Negri in the their book Commonwealth put it this way:
“In the newly dominant forms of production that involve information, codes, knowledge, images and affects, for example, producers increasingly require a high degree of freedom as well as open access to the common, especially in its social forms, such as communication networks, information banks, and cultural circuits. Innovation in Internet technologies, for example, depends directly on access to common code and information resources as well as the ability to interact and connect with others in unrestricted networks”
In other words, to be productive in this kind of work people need to be free to communicate and experiment, which is anathema to many management regimes in the public and private sectors. A similar point is made from the opposite side of the political spectrum in a popular book from the corporate side of the fence on the subject of solving the productivity crisis in the modern workplace. ‘Wikinomics’ by Don Tapscott and Anthony William looks at how corporate business is trying to understand and harness these factors. It’s a good read and reinforces that this is really a pressing issue that won’t go away anytime soon.
My own conclusions?
The key to productivity in software development lies in these tricky soft issues. One, more enlightened, software manager I have met states about prospective employees, “I am not just interested in the skills they currently have, in fact that is the least important, but their attitude and ability to learn, develop, grow and support their colleagues is crucial”.
And just to throw a curve ball into these discussions. As a second example of dysfunctional non-productive working cultures; I also worked on a large open source software project where the developers were left to do their own thing, blowing lots of dosh in the process and hyping it up big-time at international conferences (you’ll get no prizes for guesing we are talking academia here ), it ended up crashing and burning quite spectacularly.
In both my examples some of the management (and some of the developers) were certainly a bit; deluded, incompetent, greedy, arrogant, (delete as appropriate). But, these two projects also had an one very important common factor in common; their attitude to users and the amount of user testing that went on. Both projects carried out little or no user testing. When the open source developers met their users they told them they were wrong (!) and the other, ‘zombie’ project, substituted reading reports from ‘experts’ instead of testing with real users.
What I learnt from this was that the type and amount of user engagement is a useful test for the health of a software project.
