I read Peopleware last week, and was surprised to find that it referenced Christopher Alexander's work on design patterns in architecture, as these relate to laying out working spaces for developers. I was struck by the notion of an intimacy gradient, where a household has public areas (a dining room or sitting room), then shared private areas (a kitchen, perhaps), and then individually-private areas (bedrooms, studies). Peopleware proposed that we lay out spaces for programming teams in a similar way; meeting areas, then common areas, then private offices.
This all seems very reasonable, but I find myself lately working on geographically distributed teams reshuffled about quarterly, with most of our communication happening through slack. There is a persistent pattern where a new team is formed (administratively; hardly to the level of unit cohesion that Peopleware would ask of something called a team), and someone creates a slack channel for that team and invites all the formal members of the team. Gradually, more and more people from outside the team end up in the channel; sometimes they're experts in a particular thing that are called in for a particular question, sometimes they're managers or executives who invite themselves, sometimes they're just curious engineers trying to maintain situational awareness (I have been guilty of this). As the number of people increase, conversations tend to get sidetracked (or be off topic from the start), bystander effects increase, the SNR drops, and the utility to the team deteriorates.
To use Peopleware and Alexander's language: a shared private space for a team becomes a public space over time. While we have the technical means to kick people out of channels (or should I say rooms?), it's never been done; it's outside the norms of our microculture. In short: we're wusses.
My solution, on realizing the nature of this problem,was to create a direct message set with the other members of my team (so now we have effectively a public channel where management can ask us questions, and a private channel where we can figure out our collective answer before replying). So far this has been very productive, and it is immune to gradual dilution. It does produce a potential gap in organizational memory, though - if a new person is added to the team, they can't search that DM channel's history.
This realized parallel between slack and the architecture of working spaces raises some interesting questions about the social parts of the web generally. I am sorely tempted to go hunt down a copy of Alexander's book, A Pattern Language, and see if there are more elements applicable to the design of digital spaces where people live and work, again by the "room" metaphor.
While investigating Alexander's work, though, I learned that it was the inspiration for the whole software design patterns set of memes. I had heard of them, but had mostly seen them in code that I considered quite ugly, and so found them distasteful. Reading more about them now, I have not found any evidence strong enough to shake that distaste. I think at the very least, the method used to arrive at them is unsound. When Alexander derived architectural design patterns, he did so from a thousand years of functional architecture, developed at global levels of parallelism and leaving behind concrete artifacts amenable to public study. When the Gang of Four derived software design patterns, they did so from a bare half-century of object-oriented programming (which, as for example Norvig notes, is hardly the only reasonable idiom for programming). Software engineering as a discipline does not have the corpus of high-quality, environment-adapted folk-work that architecture does. Most of what we build is crap that evaporates in a decade or less, and the projects that survive do so not because of their great and highly-functional architecture but on the whims of the market. It is still very early days to be inductively drawing software design patterns with anything like the authority that Alexander can achieve with architecture.