Software Teams as Learning Systems

In sixteenth-century Florence, a group called the Camerata — musicians, poets, philosophers, scientists, astrologers — gathered under the sponsorship of Count Giovanni d'Bardi with a shared dissatisfaction: polyphonic music was intellectually rewarding but emotionally opaque. What if, they asked, you could actually understand the words? Over several decades of argument, experimentation, and rivalry, they invented opera. They also produced an extraordinary number of individually accomplished people — enough to have Wikipedia articles four centuries later, which is a decent proxy for historical significance.¹

Jessica Kerr uses the Camerata as the organizing metaphor for something she's observed in software teams. The pattern repeats: Von Neumann and his Hungarian high school classmates at Los Alamos. The Impressionists in Montmartre. The London ThoughtWorks group around 2003-2006 that gave us continuous integration, continuous delivery, and DevOps. The early Spring team that made Java development less painful and produced an improbable number of founders and CEOs. In every case, Kerr argues, "great teams make great people" — not the other way around.

Symmathesy

The theoretical framework Kerr reaches for comes from Nora Bateson, daughter of cybernetics pioneer Gregory Bateson. Classical systems thinking says a system is its components plus their interrelationships. Bateson's contribution is to point out that in living systems, the components aren't static — they learn and change. She calls this a symmathesy: a learning system composed of learning parts.

A software team is a symmathesy. The people learn. The code changes. The tools evolve. And all of these adaptations feed back into each other. This isn't just metaphor — it has practical consequences. Kerr identifies several:

Downhill Invention, Uphill Analysis. It's cognitively easier to build a system from scratch than to understand an existing one, because you construct the mental model as you go. This is why there are a thousand JavaScript frameworks — it's less effort to write your own than to truly grok React. It explains Not Invented Here syndrome, the seductive appeal of greenfield development, and why onboarding new developers is so hard even when the existing codebase is well-documented. The original developer has a rich mental model that they can't easily transfer.¹

Generativity over Productivity. Productivity is your personal output. Generativity is the difference between the team's output with you and without you. You can be highly productive while having negative generativity — hoarding knowledge, creating bottlenecks, writing code only you understand. Conversely, someone whose own output is modest but who teaches, unblocks, and grows everyone else has enormous generativity. The paradox of automation has an analog here: optimizing for individual productivity can degrade the system's capacity to learn.

The Line of Representation. Developers can't look directly at running software. They observe it through screens, logs, error messages, dashboards — tools that sit on the "line of representation" between humans and the system they're trying to understand. Investing in those tools is investing in the symmathesy's ability to learn from itself.

The opposite model

The NASA shuttle software group, the most successful software team in history by defect rate, worked on radically different principles. Their culture was "aggressively intolerant of ego-driven hotshots." Individual creativity was explicitly suppressed in favor of process. No one person was ever solely responsible for writing or inspecting code. The process was designed so that no particular person was essential.²

At first glance this looks like an anti-symmathesy — a system that deliberately prevents its parts from learning and changing. But I think that's wrong. The shuttle group had tremendous institutional learning — their error database going back twenty years, their process models that predicted expected defect rates, their practice of tracing every bug back to the process failure that permitted it. The individual learning was constrained, but the organizational learning was exceptional. They'd just located the intelligence in the process rather than in the people.

This works when you have a single product, a single customer, complete requirements, and unlimited patience. It doesn't work for the kind of software most people build, where requirements shift, the customer is everyone, and you need to ship next week. Which is why the Camerata model — diverse people with complementary skills, arguing productively, iterating fast — describes most effective software teams better than the shuttle model does. But the shuttle group is a useful reminder that there's more than one way to organize collective intelligence.

The gap between users and programmers

There's a deeper question lurking here: who gets to be part of the symmathesy at all?

Ink & Switch's research on end-user programming traces a vision that goes back to the 1960s — computing where everyone can reach in and modify their tools. Smalltalk, Logo, Unix pipes, spreadsheets, HyperCard, HTML: all of these were attempts to put programming within reach of non-programmers. And some of them succeeded spectacularly. Spreadsheets are arguably the most successful programming environment ever built. HyperCard gave birth to the first wiki, which led to Wikipedia.³

But despite forty years of work, "our computing devices are less programmable and less customizable than ever before," the Ink & Switch team writes. Your phone is an appliance. Your apps are black boxes. The distance between "user" and "programmer" has widened, not narrowed.

Jack Rusher's "Stop Writing Dead Programs" argues that this happened partly because we've been building the wrong kind of software environments. Most programs are "dead" — you write code, compile it, run it, observe the result, then repeat. Live programming environments, where the system is running while you modify it and you can see the effects immediately, have existed since Lisp and Smalltalk but never became mainstream. Rusher points to Erlang's supervision trees, Clojure's REPL-driven development, and Bret Victor's work as examples of what's possible when you design for liveness rather than batch execution.⁴

Dynamicland, the research project by Bret Victor and collaborators, pushes this further: a physical space where computation is embedded in paper on tables, manipulated by moving objects under cameras, programmed by typing on wireless keyboards. Omar Rizwan describes building a map kit in Dynamicland where a real estate developer, without any instruction, grabbed a "zoom and pan dial" and zoomed into West Oakland, discovering a gap in bus route coverage she'd never seen before — and they spent fifteen minutes exploring together in a way that would never have happened with an iPad.⁵

There's a tension in the end-user programming vision that I think the Ink & Switch team is honest about. Making software malleable means making it fragile. The reason apps are black boxes is partly control and partly that encapsulation is what makes them reliable. Spreadsheets succeed as end-user programming precisely because they have a constrained model — cells, formulas, references — that's powerful enough to be useful but limited enough to be learnable. Every attempt to create a "real" programming environment for non-programmers either stays too constrained to be general or becomes too complex to be accessible.

What software teams are for

Kerr's argument that "software is not a craft and not an art — it is the next thing after art" is a big claim, and I'm not sure the analogy to the Renaissance fully holds. But the core insight lands: the unit of software creation is not the individual developer but the learning system of people, code, and tools. The shuttle group located that learning in the process. Kerr's cameratas locate it in the relationships. End-user programming tries to widen the circle of who gets to participate.

What connects all of these is the recognition that building software is fundamentally about building and sharing mental models — of the system, of the problem, of each other's understanding. Every language design choice, every tool, every process either helps or hinders that shared understanding. And the hardest part isn't writing the code. It's getting the model from one person's head into another's, or into a form where the system itself can embody it. That's what software teams are actually for.