Software collaboration patterns

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…).

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?


Posted

in

,

by

Comments

20 responses to “Software collaboration patterns”

  1. Bill McNeill Avatar

    It doesn’t scale to an entire team by design, but Pair Programming is a codified social arrangement for producing code.

    1. Jeremy Avatar
      Jeremy

      Pair programming is a neat case to think about. I’m pretty sure that it’s slightly lower-level (more “tactical”, less “strategic”) than the level of pattern I’m looking for, but it’s definitely a codification of useful collections of interaction styles. Suzette Haden Elgin described “fixing the car” as a social-collaboration metaphor, and that’s a bit more widely understood (at least among folks of a certain social class and gender) as a certain form of collaborative effort that could be generalized to teamwork projects like software.

      1. Bill McNeill Avatar

        I guess I’m the wrong gender and/or social class (okay, probably social class), but what is the “fixing the car” model? Is that another way of saying “A-Team”: i.e generalists who have one speciality each?

        1. Jeremy Avatar
          Jeremy

          you’re the right gender, but maybe the wrong social class. For a mental image of “fixing the car”, think of four or five Sharks standing around the open hood of a 1950s automobile, with one guy leaning in with a wrench and the others standing around with beer and cigarettes, commenting and making suggestions. A sort of collaborative problem-solving that’s very cooperative and also very male-gendered.

  2. Bill McNeill Avatar

    This is an interesting question and one difficulty with finding an answer is guys like me who have spent their entire working lives in software, and so don’t have a first-hand outside perspective.

    Thinking about team situations in other professions friends have told me about, they seem mostly command-and-control based. Hospital nurses have a very regimented system–much more so than developers–but that makes sense because they don’t have to create new things, but they have to be very sure not to have details get garbled in miscommunication because that could kill somebody.

    I wonder if a useful comparison would be general contracting work. Again there isn’t the emphasis on novelty, but doing work on an existing structure shares with software the inability to foresee snags in the road. A contractor looks at a wall and says, I know there are unexpected problems lurking behind that sheetrock, I just don’t know what they’ll be. This is reflected in built-in contingencies in schedules and budgets, which is a software tactic as well. I’m not sure if there are management parallels.

    1. Jeremy Avatar
      Jeremy

      Social and personal guidelines for working with the unknown are absolutely what I’m looking for here. the Star Trek (“Bridge Crew”) metaphor has that built right in, but — as suggested above — has some xenophobic (“Not Invented Here”) angles on it that are a bit toxic if taken too seriously.

  3. […] ← Software collaboration patterns […]

  4. Bill McNeill Avatar

    God help me, but this post is making me want to read management books.

    1. Jeremy Avatar
      Jeremy

      Oh, I’m so sorry, Bill.

  5. Bill McNeill Avatar

    A solider it is commonly said (in Men Against Fire inter alia) fights not for his country, but for the guy next to him. Similarly, though strategic goals (career advancement, stock price) may hold sway at review and quarterly meeting time, what motivates programmers on a day-to-day basis is the respect of the five or so other programmers they work with most closely. You want them to think that you are clever. You don’t want to let them down. The most successful software situations I’ve been in have traditional top-down management but we suffused with lots of mutual respect and affection. The Collegial Waterfall. Of course, “make everyone like each other” is closer to a restatement of your original problem than a proposed solution, but in social engineering, mutual respect will always result in reduced organizational friction, but the converse is not guaranteed.

    1. Jeremy Avatar
      Jeremy

      I think this *is* a restatement of the challenge, but a useful one, because it’s making explicit one of the criteria I care about: in the desideratum pattern, we want *mutual respect* to be part of the expectation from colleagues.

  6. […] been exploring patterns for actually working on software — not for designing it — and I realized that […]

Leave a Reply

Your email address will not be published. Required fields are marked *