Teams and All That

“The construction of software is an essentially social activity typically performed by anti-social people.”

I don’t know who said that first. I doubt it was me, but I’ll take credit for it if no one else will. Or maybe I’ll take the blame. After all, the construction that we who code are anti-social by nature is a convenient construct, just as the neck-beard and the particularly pernicious “you don’t look like a software engineer” have served to pigeonhole — and thus devalue — those who practice our craft.

Stereotypes are rarely cut from whole cloth though. Those who create stereotypes are just not that good at what they do. Consider the normal view you get of coders coding: A line of people staring at one or more screens (often artfully placed), locked-in, headphones (actual or virtual) strapped on, spouting a notable series of oaths out into the cosmos at irregular intervals, punctuated by brief smiles of self-satisfaction. Yes, we do that. Yes, we do that more than a little.

But there’s so much more going on. First of all, little software these days is the product of a single mind. Problems tend to be broad, requiring input from a series of people grounded in different disciplines. Solutions tend to be no less broad, requiring the use of multiple tools from multiple cognitive toolsets. But the mind that can focus equally well on data collection and frontend design, distributed processing concerns and architecture at multiple levels is both exceedingly rare and, seemingly, if you listen to most management rhetoric, in constant danger of either winning massive lottery prizes or being crushed by rogue, on-road, public transportation.

So we build teams — or we try to. We try to build stable, self-regulating teams with a wide array of complementary talents that can build useful software within a palatable time frame. And I say “try to” because it’s damn hard to do. It’s difficult enough to find a minimal group that can cover all the conceptual needs, making sure the human dimensions are covered as well makes the process an order of magnitude more difficult.

But what does a team look like? Well, there’s the “two pizza” rule. No more active members than can be fed with two pizzas. That sets a limit of eight or so. It’s a pretty good limit; any more than that and you start needing internal management (just on a human level) and standups and such quickly become interminable. You also need able representatives of the various stakeholder groups within an organization, where ‘able’ refers to being empowered to make all but the most major calls, otherwise the call chains get unacceptably long.

It’s a non-trivial exercise to be sure.

But, actually, it’s worse than that. Not only do you need to make sure all needs are accounted for under optimal circumstances, you also need to make sure that you at least get close under suboptimal circumstances — which is, frankly, just about always. People get sick. Take vacations. Are unavailable due to some special project. Or a conference. In fact, as soon as you get to the point of having enough people to make a team truly viable, you reach the point where it is more likely than not that some member won’t be available at any given time.

So, OK. It’s impossible.

But just because it’s impossible, doesn’t mean it’s not worth trying. It’s actually essential. If Conway’s Law holds at all, that is.

And when you have a team, or part of a team, or even the germ of a team, by all means nurture it.