Defining Developer Collaboration

Editorial Note: I originally wrote this post for the SmartBear blog.  Check out the original here, at their site.  While you’re there, take a look around at the pieces written by other authors as well.

A certain ideal of rugged individualism has always permeated programmer culture, at least in some circles. It’s easy enough for writing code to be a highly solitary activity. There’s a clear set of rules, output is a function of input, feedback is automated, and the profession tends to attract night owl introverts in many cases.

The result is a history punctuated by tales of late night, solo efforts where someone stares at a computer until overcome by sleep. Obsessed, brilliant hackers expend inconceivable efforts to bring amazing open source tools or useful libraries into existence. It squares with movies, popular culture, and our own knowledge of our profession’s history.

And yet, how many significant pieces of software are developed this way anymore? This ideal was born into a world where complex software might have required 10 thousand lines of code, but does it carry forward in a world where 10 million lines are common? Even projects started by individuals on a mission tend to wind up on Github and to gather contributors like a snowball rolling down a mountain.

Today’s technical landscape is a highly complex, highly specialized, and highly social one. In a world where heroic individual contributions are increasingly improbable, collaboration becomes the name of the game. Like it or not, you need other people to get much done because the work and the breadth of knowledge tends to be too much for any one person.

Defining Collaboration for Developers

I’ll spare you the obligatory, “Webster’s Dictionary defines collaboration as…” It means what you think it means: people working together. I’d like, instead, to establish some axiomatic ground rules in applying the term to the world of software development.

The first requirement is, of course, that you need to have more than one human being involved to consider the effort to be collaboration. The mechanisms, protocols and roles can vary widely, but table stakes require more than one person.

The second requirement is that the participants be working toward a shared goal. Without this, a bunch of people in a coffee shop could be said to be ‘collaborating’ simply by virtue of colocation and the occasional, polite interaction. Collaboration requires multiple people and it requires them to be united in purpose for the activity in question.

A final and developer-oriented requirement is that the participants must be working on the same work product (i.e. codebase). Again, consider a counter-example in which iOS and Android developers could be said to be ‘collaborating’ since there are more than one of them and they’re united in the purpose of improving users’ smartphone experience. Their shared purpose has to bring them together to work on the same actual thing.

Really, though, that’s it. More than one person, united in purpose and working on the same thing, are necessarily collaborating. Whether they do it well or not is another matter.

Functional and Dysfunctional Collaboration

To understand what I mean about bad collaboration, consider an extreme example. Two developers are working on a codebase. The first developer spends most of each day writing code and then she checks it in. The second developer then pulls her changes, dislikes them, and promptly reverts all of them, resulting in almost nothing ever getting done or changing in the code.

Are these developers collaborating? Well, yes, actually. There’s more than one of them, they are united in purpose (maintenance/extension of the software), and they are working in the same code. It’s easy to conclude that this sort of antagonistic, passive-aggressive interaction means that they are not, in fact, collaborating. But they are – it’s just a very dysfunctional collaboration.

In a profession with very individualist, loner roots, collaboration often does tend toward dysfunction. It probably won’t be quite as broken as the scenario I’ve just described, but it is often far from ideal. Egos compete, introverts withdraw, people hide behind emails and processes, and the train just generally creaks, sways, and threatens to go off the rails.

The goal of collaboration is, at its most simplistic, to generate more output more quickly than would be possible by a solo effort. But, above and beyond that, teams strive to be more than the sum of their parts. This makes eliminating dysfunction critically important, because dysfunctional teams and their collaborations wind up being less than the sum of those parts.

Getting it Right

I will say straightaway that I have no magic formula for the egos on your team and for cajoling the people on your team to get along. That’s really hard, and it really varies from team to team and personality to personality. And, frankly, harmony is not always required to make a team more than the sum of its parts. But productive collaboration is required, and that’s what you should aspire to.

The first thing teams need to do is make sure that they are polite and professional. They can disagree constantly and even dislike one another, but the discourse has to remain civil, or professional disagreements (which can actually be beneficial) will metastasize into counterproductive personal feuds. Once it gets personal, it’s hard to recover without altering team personnel.

Upon a foundation of professionalism, you should build a culture of honest review and feedback. Professionalism is key because it makes the feedback constructive and valuable as a opposed to tit-for-tat sniping. But the feedback is good for the work product’s quality and for the team members themselves. Having their work reviewed constructively makes them better at what they do.

And, speaking of team member improvement, good collaboration requires the sharing of knowledge. Knowledge sharing is good for the team members for very similar reasons – learning from their team members makes them better professionally. It’s also good for the organization in that it prevents human bottleneck situations where a team member’s absence stops all productive work.

The Importance of Collaboration

In this day and age, it’s pretty likely that a given software application will require knowledge of 10 or more different languages, frameworks, and technologies. It’s also likely that the application will need to change rapidly to keep up with the rapid pace of change. In the face of these challenges, forming a team is necessary and getting that team to collaborate is critical.

I doubt many would dispute this, and yet, all too often, the subject of how to collaborate productively gets only cursory attention. You don’t need offsite team-building exercises and therapists to do good work, but you do need to understand what collaboration is, what it requires, and how to get the most out of it. Without that understanding, you’ll bob along, perhaps staying afloat. With it, you’ll have a team that’s more the sum of its parts and that’s heading in a good direction.