To quote Wikipedia: an anti-pattern is:
a pattern used in social or business operations or software engineering that may be commonly used but is ineffective and/or counterproductive in practice. [emphasis mine]
I’ve been exploring patterns for actually working on software — not for designing it — and I realized that I myself spent a lot of time living inside one particular pattern, which we might call the Grad School collaboration anti-pattern.
Grad school — especially the process of writing a PhD — values three things, no matter your department or specialty:
- novelty – what you create must be different from what everybody else until now has done
- individual effort – what you create must be your own work, not something produced by a team
- completion over sustainability – sometimes called “PhinisheD”, or “the point of a PhD is to finish a PhD”.
Each of these targets is critical to the idea that a PhD is a work of heroic individual effort to expand the boundaries of science. This idea is a fiction, and — like so many useful fictions — is a useful fiction, though it’s rarely true in practice (my PhD, for example, was a product of my labmates and fellowship [ETA: and of course my own effort!]).
But each of these is actually a collaboration anti-pattern of its own:
- novelty can spiral off into Not Invented Here — and frequently does
- individual effort fosters “Colleague, pronounced as “competitor”
— many, many escape grad school (or not) with absolutely vicious attitudes towards others working on related projects
- completion over sustainability encourages the Just Ship It antipattern — most research code is so heavily grown into the bench that it cannot be run outside of the lab — often even the implementer him- or herself can no longer run it, by the time dissertation defense rolls around.
It sometimes astounds me that so many brilliant researchers survive PhD land — and it worries me: so many good software designers and implementers must be turned off by the dysfunction implied by each of these three.