the Origins of Opera and the Future of Programming
Or: Collective problem solving in music, art, science, and software.
At the end of this post is an audacious idea about the present and future of software development. In the middle are points about mental models: how important and how difficult they are. But first, a story of the origins of Opera.
Part 1: Examples
The Camerata
The Florentine Camerata were a group of people who met in Florence in the 16th century. They had a huge impact on history and on each other.
(Caveat: I’m not a student of music or music history. I listened to this Great Course and heard about this Camerata and noticed a resemblance to some teams I’ve seen and been in. So I looked it up further, and came upon Collective “Problem-Solving” in the History of Music: the Case of the Camerata by Dr. Ruth Katz in the Journal of the History of Ideas, and toward the end of it my mind was blown. More on that later.)
Camerata literally means a small orchestra or choir. This Camerata was a diverse group of people who gathered and worked on a common problem: they were bored with polyphony, the esteemed music of their day. (Sample: Palestrina) Polyphony is very pretty: it has around four melodies, each of equal importance. Each has a logic of its own, rather than melody and accompaniment. Polyphony is intellectually rewarding, but you need technical understanding to appreciate it fully. What feeling it conveys comes through auditory qualities.
The Camerata asked the revolutionary question: what if you could understand the words?
Methods
The Camerata included (all quotes in this style are from Katz)
musicians, artists, poets, astrologers, philosophers, scientists
who met informally under the aegis of Bardi and Corsi.
People with diverse skills and perspectives worked together. They had sponsorship; Giovanni d’Bardi was Count of Venoa, and loved to surround himself with interesting people.
Their aim was to reform the polyphonic music of the day
and they believed that the best way to do so was to renovate the ancient Greek practice of setting words to music
They shared a common goal; they were unsatisfied with what Vincenzo Galilei (member of the Camerata, father of Galileo) called “that corrupt and incomprehensible contemporary music.”
And they had a common strategy. They didn’t really know what the Greeks did, but this lent legitimacy to their ideas. Like citing computer science papers from the 70s.
Their real high-level objective was horizonal, and more specific than moving away from polyphony:
Their principal aim was to find the optimum formula for wedding words and music.
Here, “optimum” is measured as “maximally effective in communicating… the specific meanings and emotions appropriate to the text.”
Qualities
The Camerata talked a lot, and listened to each other talk.
“I learned more from their learned discussions than I learned from descant in over thirty years” — Caccini, renowned singer
(I had to look up “descant.” It means long-winded discourse. Like you’re experiencing now, sorry.)
But they weren’t all talk.
the Camerata constituted not only a forum for theoretical discussions, but also a workshop, a “laboratory” for the creation and performance of music.
They practiced together! And experimented. The beginning of the scientific method is a big part of the Renaissance, and it intertwines with art. We have a new way of thinking, ways of asking the universe questions. Vincenzo Galilei varied lengths and tensions of strings and found the ratios that make chords.
The Camerata didn’t always get along. There was rivalry between Bardi and Corsi, the two chief sponsors. Bardi preferred talking, Corsi wanted to play more music. These feed each other. There was disagreement over style between Caccini and Peri, the two musical stars. Peri wanted to focus on the words, with a bit of music; Caccini wanted the singing to stand out, while also understanding the words. These tensions lead to a balance.
They did code review!
presentations made… were commented on formally by “defenders” and “censors” who were nominated for the occasion.
I like that criticism came from people designated to the role, not the asshole who doesn’t like you and takes it out on your code. (Technically, this took place in the Alterati, another meetup with a lot of the same people.)
Outcomes
Over the years, this team changed history. They invented the music-drama, and a style of music that conveyed more meaning. (Sample: Monteverdi, a first composer to adopt the Camerata’s style. If you know Italian, you can probably understand the words.)
What about the individuals? Their outcomes were exceptional too! Here are some of their publications:
As composers of operas and authors of scientific treatises, these half-dozen people are fewer than half of the Camerata members who have Wikipedia articles. Really, what are the chances, if you’re alive in the sixteenth century, that you have a Wikipedia article today? These people did pretty well for themselves. They grew out of the Camerata.
Also in Science
This pattern of a group of people coming together to solve a problem is not unique to music — it’s the common case.
the Camerata resembles the kind of “invisible college” which is the key to creativity in science.
This “invisible college” is an association of people who share ideas. Who build a new reality together, then spread it to advance the wider culture.
We like to give the Nobel Prize to one or two people. But who worked in their lab? Who did they correspond with?
When Jon Von Neumann went to Los Alamos for the Manhattan Project, so did two or three mathematicians that he went to high school with. Really, you grow up in Hungary, what are your chances of getting to Los Alamos? They built each other up.
These invisible colleges share:
tacit understandings concerning appropriate methods of research
(processes and values)
priority problems
(this means they fight over who was first; more on this later)
and the shorthand communication which shared work implies.
We can move quickly together because we share common ground, compatible mental models. This is super fun, when I get to this point with my team.
Also in Art
People work together to develop their individual styles. Usually in Paris, it seems.
the salon, the coffeehouse, the café as breeding places of artistic creativity
In the nineteenth century, a group of artists broke from the mainstream and developed Impressionism.
coping with a common puzzle which they, separately and as a group, tried to solve
Van Gogh lived in the Montmartre district with the other artists and dealers and critics. When I visited his museum in Amsterdam, my favorite part was all the paintings by his friends and associates; they developed each other as painters.
One of these (my personal favorite) was Paul Gauguin, the one Van Gogh cut his ear off over. Gauguin went on to influence Picasso.
Picasso was at the center of many social circles in Paris over the decades. Writers, photographers, philosophers.
One painter who dipped in and out of his camerata was Aleksandra Ekster, who took the ideas of Cubism back to Kiev, where her studio was its own place of idea exchange.
One of her high school classmates and friends was Alexander Bogomazov, and a print of his lives on my bedroom wall.
This brings us to the modern day, where we can find examples of this phenomenon in software teams.
Also in Software
One camerata emerged in London around 2003–2006. This group gave us Continuous Integration, Continuous Delivery, DevOps. Many of these people worked at ThoughtWorks. They weren’t all on the same project, but they talked to each other, and they solved the problem of: Does deployment have to be so hard?
Jez and Dan and Chris Read produced The Deployment Production Line. Later, Dan went to invent BDD, Sam Newman became a prophet of microservices, and more. I keep meeting conference speakers who were part of this group.
Another example: the early Spring team, around the same time. They came together online, from all around the world, to solve the problem of: do we really have to use J2EE? and made Java development less painful for everyone. Today, Java development is (approximately) everywhere, and Spring is everywhere Java is.
That group of developers and businesspeople produced an inordinate number of founders and CEOs and partners.
Personally, I’ve been part of three teams that grew me as a developer and as a person. The tech meetup scene in St Louis is a source of growth too. We have several groups of about twenty, and a lot of overlap so we can talk to the same people multiple times a month about interesting things.
In all of these examples, we can observe a phenomenon:
Great Teams Make Great People.
You don’t hire star developers, put them together, and poof get a great team. It’s the other way around. When developers form a great team, the team makes us into great developers.
Part 2: Theory
Why? Why do great teams make great people?
I have a theoretical framework to explain this.
It starts with Gregory Bateson. His father, William Bateson, invented the term genetics and pulled Mendel’s work out of obscurity (with the help of a team of people: his wife and other women, since proper biologists at the time scoffed at this work). Gregory Bateson had a camerata: the Macy Cybernetics Conferences, a series of ten conferences over several years sponsored by the Macy Foundation to advance medical research. Gregory Bateson was a pioneer of cybernetics, now known as Systems Thinking.
Systems thinking is to the present era what the scientific method was for the Renaissance. It is a new way of analyzing problems and experimenting.
Another of his contributions: his daughter, Nora Bateson.
She takes systems thinking a step past where it was in her father’s day. In the 1950s-1970s, scientists put tons of numbers into computers and attempted to model entire ecosystems. Catalogue all the parts, and all the interrelationships between the parts, and we can understand the system and predict outcomes, right?
Not so. And it isn’t for lack of numbers, and details, either. Nora Bateson points out that there’s more to a living system than parts and interrelations: the parts aren’t constant. We grow and learn within the system, so that the parts don’t stay the same and the interrelationships don’t stay the same. She gave a word to this, something deeper than any mechanical or model-able system, a learning system composed of learning parts: symmathesy (sim-MATH-uh-see).
When we look at a living system (a team, say, or a camerata), we can see the parts. People, and our environment (like our desks and computers).
Systems thinking says, we are more than the components; we are also the interrelationships. Agile recognizes that these matter.
But there’s more! Each member of a team learns every day. our environment learns and adapts too, because we change it.
This is a symmathesy. “Sym” = together, “mathesy” = learning.
We work and grow in a symmathesy. This growth results in great people.
This also explains why it is important to bring our whole selves to work: to build this living system, we need to be alive in it.
Teams Developing Software
There’s something extra special about development teams: software is the most malleable material we’ve ever used in engineering, by thousands of times. There’s nothing else like it, and this changes the meaning of “team.”
A team consists of everyone required for me to be successful, regardless of what the org chart says. Success is running useful software that impacts the world outside my team.
My team includes the people I work with, and also the software itself. And the servers it runs on, the databases it uses, and all the tools that we use to interact with the running software: the code, version control, automated tests, deployment scripts, logging.
The software is part of the symmathesy. We learn from it, from its error messages and logs and the data is collects. It learns from us, because we change it!
As long as we can change it, the software is vitae in our symmathesy. We form a sociotechnical system, people and running code. We build this system from within. No wonder this work is challenging!
Programming wasn’t always this hard. Back when I started, I worked on one program, making the changes someone asked for. For data questions, I asked, “How do we use the database?”
These days, I ask, “which database shall we use?” (Or databases.) And how will we get from here to there? I spend more time on, which work should we do? how will we know it’s useful? My perspective includes our whole software system and team, and surrounding systems too. The scope of the system we can hold in our head is the portion of the system we can change.
Mental models
In order to change our system, we need a mental model of it. Each developer has a mental model of the software we work on. Each developer’s mental model is necessarily incomplete and out of date. And, they’re each different from everyone else’s. (this is called Woods’ Law, if I recall correctly.)
We spend time reconciling our mental models enough to communicate with each other; this is a coherence penalty.
Accurate mental models are incredibly powerful. They let us decide how to change a system, how to know whether it worked, and where to watch for extra consequences. They’re also incredibly hard to form and validate. I’ll call out two reasons in particular for this difficulty.
Line of Representation
A developer can’t look down and see the software running. It is made of dynamic processes running in some digital space that we can’t see into. Until TRON is a thing, we can’t go in there and talk to it. This barrier is called the Line of Representation. (DD Woods et al, STELLA Report)
We can only look at screens and type on keyboards; we use software to observe and control other software. Each of these tools is part of our symmathesy. Grow them, and they can grow the accuracy of our mental models.
I like this diagram because it lets me explain my job at Atomist in one sentence: we make tools to help you move tasks from above the line to below the line. Continuous integration is a step in this direction; Atomist takes it farther.
Downhill Invention, Uphill Analysis
This is counterintuitive: it’s easier to build a system from scratch, constructing the mental model as you go along, than to form an understanding of how an already-built system works.
Valentino Braitenberg illustrates this principle in his book Vehicles. He calls it the Principle of Downhill Invention, Uphill Analysis.
Why are there a thousand JavaScript frameworks out there? because it’s easier to build your own than to gain an understanding of React. Even with hundreds of people contributing to documentation, it’s still more mental effort to form a mental model of an existing system than to construct your own. (I didn’t say it was faster, but less cognitively strenuous.)
Not Invented Here syndrome? laziness. Greenfield development? Of course people like it! it’s much easier than getting your head around legacy code.
When you do have a decent mental model of a system, sharing that with others is hard. You don’t know how much you know. If you’re the purple developer in this picture:
then you have a mental model of this system because you built it. The green and blue developers have been assigned to help, but they can’t change the system because they don’t understand it. Meanwhile, you may be changing the system fast enough that it’s impossible for them to get a grasp on it, no matter how smart they are. (I’ve been in their situation.) The solution is to work together on the system, and invest attention in transferring your mental model. Until then, Blue and Green get in your way.
Which developer in this picture is ten times more productive than the others?
Individual vs Group Interests
This brings us to the conflict between advancing your own reputation and contributing to the group.
The race to be first has to be reconciled in science with the need and the norm of sharing.
Following the Camerata’s work, Caccinni argued with Peri and Runiccini and Cavalieri (who was not a member, but corresponded with the Camerata) over who invented the stile rappresentativo, that amazing innovation of one melody plus some accompaniment.
When people are evaluated as individuals, there’s incentive to hold back from sharing. To hoard recognition.
Recognition and esteem accrue to those who have… made genuinely original contributions to the common stock of knowledge.
This is dangerous, because the useful ideas are the ones we contribute. The mental models we hoard make us look good; those we share make the whole team powerful.
Generativity
Productivity is my personal output. Generativity is the difference between the team’s output with me and without me.
It’s possible to be quite productive personally and have negative generativity, holding the rest of the team back. It’s common to see a person whose own work is slow, but who helps and teaches everyone else. If we start recognizing and crediting generative actions, we build our symmathesy.
The output of everything we do is some side effect on the world and the next version of ourselves. Generativity is about growing the team’s output over time, and each member of the team grows at the same time.
Obliquity
It’s counterintuitive: to become great, put the team first. Aiming first for my own greatness, I limit myself.
Great developers aren’t born.
They aren’t self-made.
Great developers are symmathesized!
(sim-MATH-uh-sized)
Part 3: Predictions
There’s one more piece of the Camerata’s story that surprised me, that gave me a new idea about today’s world.
Surrounding Culture
The Camerata existed in the late Renaissance.
there was a sense of innovation in the air
When the world is ready for an idea, it doesn’t come to just one person.
the Camerata “were like midwives to a sixteenth century which was pregnant with the peculiar conjunction of social, ideological, and cultural ideas and practices from which the opera emerged.”
It was a time of increasing variation; regional and local distinctions emerged, in spite of the Church aiming for uniformity.
the very existence of such groups as social institutions was a product of the time
Right now, the software industry is letting teams try things. Developers are hard to hire, and the work we’re doing is hard, so we get to experiment, even though companies prefer uniformity.
We contribute to the larger world by learning and spreading new practices. Ideas from agile development have spread into other business areas and improved lives.
I’m glad to be alive at a time of cameratas.
Recognition of Art
Somewhere around the beginning of the Renaissance, there was a shift in the way painters, poets, and musicians worked. They used to be tradesmen: they had guilds and apprenticeships. Painters learned how to paint, and musicians how to play the instrument. This guaranteed competence; if you hired someone to paint a scene, they could paint something reasonable. It didn’t guarantee talent; guild membership was more about whose kid you were.
During the Renaissance these guilds lost power. Competence was harder to guarantee, but individual talent was recognized. Painters and poets specialized in subject matter. People noticed that there was some common factor to music, painting, poetry, drama — some indefinable essence that was more than competency with a brush.
Some spark. some Art!
Before, as tradesmen, painters hung out with painters, sculptors with bronzeworkers etc. After Art became a thing, artists studied in academies, and they talked to intellectuals of many kinds.
transformation of homogeneous artistic circles into “cultured” circles: poets, artists, amateurs, and laymen alike.
It reminds me of a move from typing Java in a cubicle into an agile team, with discussions including designers and testers and businesspeople. I’m no longer painting in acrylics. I’m painting something.
Software is not a craft.
We aren’t housepainters. Competence is not supreme in a shifting, complex system. Our users’ needs change, our technologies change, and every change we undertake is one we’ve never made before. We cannot possess all the skills we need; our secret weapon is learning, never perfection.
Software is not an art.
Neither are we creating a portrait or a poem, where there is such a thing as “done.” What we build affects people more directly than works of art. To do this it must keep running, it must work on their devices, it must keep changing. Software has a greater power to change people by changing the world, but these systems are more than one person can make, and they never complete.
Serious software development is the practice of symmathesy.
Software is not Art. Software is the next thing after art. It is something new, that we’ve never been able to do before.
And that implies that our current time is the next thing after the Renaissance. We are developing whole new ways of being human together. I am thrilled to be a part of this, and to be in the thick of it. To be more than a craftsperson, more even than a developer.
I am a Symmathecist, in the medium of software. (sim-MATH-uh-sist)
I want to practice symmathesy, to grow as part of a growing system, a system with people of many different skills. I want to care for and change software that changes the world outside my symmathesy, even as it changes me.
The only problem with this idea is that it has my name on it. Ideas are only valuable when they’re shared, spread, contributed to the common knowledge. Every person who spreads an idea is part of it. So join me, spread this.
Do you have a camerata? Can you help build one?
How do you practice symmathesy, consciously? How can we educate ourselves and each other in this practice? Are you a symmathecist, too?
The camerata changed history; we feel their impact every day. (Sample: my daughter singing Hamilton, the modern music-drama.)
So will we.
If you like this, join my newsletter for more along these lines.
