Software development is a fundamentally social process: it’s all about working together. We (software developers as a caste) have expressions like “programming by contract” and design patterns like “Delegation” that reflect how we humans work together – and we use these patterns to describe how we instruct our robot minions to function. We think about our programs with social metaphors because we’re social apes: we think well with social metaphors, and our software design patterns reflect how we think best.
But we rarely use these social metaphors to think about how we make software. We need patterns for collaboration that match our social creature wetware, the way “delegation” and “factory” and “handshake” patterns help design software.
We do, as a common practice, discuss certain collaboration anti-patterns: we talk about “Wild West” software development, to disparage the developers we feel are unprincipled, and Code Complete spends chapters tarring “waterfall” design as “directing from a position of ignorance”.
Nevertheless, the social life of software dev work, for many of us, resembles little more than a military command and control structure, bound by status, authority, and dictation. There are good reasons that command and control social structures like the military donated the acronyms SNAFU and FUBAR to hackerdom (FUBAR made its way into hacker metasyntax!). These words reflect the frustrated perspective (“situation normal”!) of a trench private who knows that no matter who will give the orders, it’s the private who risks his neck.
We are in desperate need of teamwork patterns that are neither “Wild West” nor “Command and Control”.
The recent rush towards so-called “agile” practices (a naming coup if ever there were – contrast “scrum”) have been an attempt to generate new collaboration patterns, but these are taken – usually – as a list of tactics (“five minute stand-up meetings!” “Index cards!”) rather than an entirely new collaboration model.
So what other collaboration patterns are out there for us? As software nerds, we’re comfortable borrowing useful bits from others (that’s what open source is about!), so let’s consider:
Democratic or parliamentary process doesn’t seem feasible for developers, although the W3C and RFC processes use them. Majority rule is a terrible way to establish communities of practice: an alienated minority of even 20% will destroy a software project, and most parliamentary processes consider 80% majorities to be “overwhelmingly in favor.” So democratic process is out for us, in favor of “rough consensus and running code“. But how to establish this “running code”?
A Football Team has some promise: there are “special teams” that trot out onto the field at certain moments, and a few key players (quarterbacks and running backs) make decisions “in the field”. But it’s not much different from the military-style Command and Control social organization pattern that already chafes for most developers (coaches run most of the action and never come on the field…).
A Rock Band is probably a collaboration anti-pattern. Well, when they work, it’s a magical, “structureless” whole, but there’s no obvious way to know –before joining a band — whether this will be one that works, or one where it doesn’t. And bands fail in so many ways: each musician believes they’re “carrying” the band, or everybody hates the drummer, or the lead guitarist and the singer keep fighting for the spotlight. (More reason to hate the hiring practice of advertising for “rock stars”!)
A Ship’s Crew collaboration pattern seems like a neat idea (after all, that’s the appeal of Star Trek: ToS), but is probably a little too focused on hierarchy (the captain always has the last word?). The Bridge Crew might be a bit better — everybody’s senior enough to not fight much — but it still over-emphasizes isolation from the outside world, opening up a big vulnerability to the Not Invented Here collaboration anti-pattern, not to mention the chief flaw with the Bridge Crew: what if you’re one of the Red Shirt anti-pattern victims?
Any others come to mind? (Some of you may have talked to me in person and know that I have one I really enjoy, which I’m saving for a later post.)
Is there a TV Tropes for software collaboration patterns?
Leave a Reply