A few days ago, former Guardian Technology editor Charles Arthur wrote to express his opinion that the idea that “journalists and coders should sit together to create amazing stuff” is one of the “great lies of our time”.
On close examination, he doesn’t give particular arguments against the collocation of journalists and developers. Instead, his point seems to be that these two groups cannot and should not try to work closely with each other, because they function at a different pace with opposite goals: journos need immediate results whereas devs evolve slowly toward a full product.
Reading his post made me different kinds of sad, which I would like to share, as I believe it is at least as much a story of the relationship between journalists and developers as it is a lesson in software methodology.
First, during the time Charles was editor of the Technology desk, he never came and talked to me directly even though I was a developer and subsequently technical lead on Composer, the Guardian’s new CMS. Whether he was already disillusioned by that point or not, I regret not being given the chance to work with him to disprove his argument.
Second, the solution he suggests at the end is to “keep [developers and journalists] well apart. But also have an effective manager who listens to the two groups and can tell each to do things. Have a manager who can direct them.”
At the time, most of the interactions between developers and editorial users were in fact mediated by a product manager. In retrospect, in spite of everyone in the team being smart and passionate, I consider this process was dysfunctional and prevented developers from exhibiting the type of spontaneous and creative initiative Charles attributes to journalists.
It doesn’t have to be that way, though.
As Benji Lanyado argued brilliantly in 2012, having been on both sides of the fence: rigid processes and segregation are not the way to better results and faster development; cross-skills and direct organic collaboration are, whether people are collocated or just visiting each other regularly.
Fortunately, we have learnt from past experience. In the team in charge of Grid, our new image management system, we work hand-in-hand with its users, in particular our picture editors. We all have laptops and constantly interact with them. Maintaining this daily dialogue between developers and stakeholders from editorial, as well as imaging and rights experts, is the best way to guarantee that we build the right thing and know what to move onto next.
More importantly, we are able to listen to our users’ feedback and address quick wins within hours, which is immensely rewarding for everyone involved.
We do have a great product manager, but his role is to help establish the wider vision and facilitate direct contacts between the team and the users, rather than acting as a communication proxy.
Less controversially but just as successfully, our award-winning interactive team relies entirely on the close collaboration between technical and editorial staff.
Third, I’m worried by Charles’ perception that, unlike journalists, the developers’ primary goal isn’t to deliver results quickly and effectively before moving onto the next thing.
It most definitely should be.
The entire methodology of agile software development, which we follow at the Guardian, revolves around the empowerment of the development teams to deliver useful software rapidly and flexibly in short iterations.
The ability to experiment, validate concepts, ditch failed ideas and constantly ship valuable improvements is and should remain at the core of what developers do in an agile environment. If this process isn’t clear to the outside, we have work to do to communicate it better.
This isn’t to say that journalists and developers work under the same constraints. As Charles noted, the former must deliver under constant pressure of time and accuracy, while the latter are expected to maintain the vision and roadmap of their product.
However, both share the same goal: to use their expertise and seize opportunities to deliver constant meaningful additions to the edifice they are contributing to, whether it is the corpus of editorial content, or the software that powers it.