Anti-Bias of Listening Deeply

Getting around cognitive biases (like “hindsight is 20/20” or a confirmation you expect) is akin to Listening Deeply. I don’t mean paying more attention gives better insight. I mean what matters is the entirety of your sonic awareness.

There is a composer / meditative approach to sound pioneered by Pauline Oliveros called Deep Listening. I have practiced it, all too briefly with her, but mostly with others taught by her. It is actually a discipline you can be certified to teach, which I am not, so here I refer to it as Listening Deeply.

It is something that has become an integral part of my life not only as a composer and improviser, but also in how I deal with my “monkey mind” working in technology: constantly replaying scenes from recent memory, kicking the big red “whatever you do don’t analyze this” button, attempting to deterministically predict the future based on my own excruciatingly limited knowledge of a continuously adaptive world, getting in my head while washing dishes, etc. Listening calms and centers, it leaves me more open to inspiration.

My psychological states notwithstanding, when in this mode of Listening Deeply I have noticed the ease at which I “hear sounds coming” and am not so surprised by them. I attribute it to how this kind of specialized listening can enhance the physical act of hearing complex sounds, which you may be surprised to learn is a serial activity.

record scrrrrratch…! amirite?!

Yes, difficult to fathom, but it’s (mostly) true. Of all our senses, only the sense of hearing is fundamentally serial because the anatomic structures we (and other non-human animals) evolved to survive are thanks to the nature of complex sound waves.

We may not realize that our consciousness is not called upon to immediately ascertain the streaming series of discrete pitches heard “one at a time” that lets us know it is a certain type of birdsong, breakfast frying in the skillet, or a bamboo glade. Those are all immediately recognizable mental models that we’ve learned to intuit through the experience of hearing them over and over.

So, I want to pull your focus away from the things we hear, the interpretation our brain implants about the world around us, what the confounding mystery of Cognition formulates as a ‘sound object’. Instead, consider the nature of sound as the vibration of a thing interacting with a surrounding medium through the promulgation of waves, ultimately picked up by tiny bones in our bodies.

Our ear canal is tuned finely to capture the most complete spectrum of sound allowed by the evolutionary phenotype of the human need to process sound waves. That is to say, nature selected the profile of our (quite good, but not best in the animal kingdom) hearing that pulled us along our evolutionary path to be the listeners we are today, one waveform cycle at a time.

This matches our instinct about Music. Our intuition is linked to our instincts, so even though we don’t know how to improvise jazz, we know it has a cool rhythm. Some folks nod to a hypnotic house beat, others to a hiphop groove, and the percentage of those who create all this music are as minuscule as the stapes of the middle-ear is to the rest of our skeleton.

Taking this one step further, any topic regarding sound is inextricably tied to the phenomenon of Time, and if there’s one thing Surprises in Complex Systems depend on (including jazz and networked software systems alike), it is that the Arrow of Time does not stop.

Now, back to the action of what it means to Listen Deeply. Without going into Fast Fourier Transforms and logarithmic graphs of resonance and frequency response, I ask that you trust a trained musician to tell you that our brains are REALLY GOOD at piecing together these ‘sound objects’ from the serial intake of frequencies by our (hopefully two good stereophonic) ears. For now, we’ll also ignore the fact that you hear yourself primarily through the bones in your head, and some modern amplification and hearing-aid technology exploits this in wonderful ways. Not the point.

The point is also not that I am somehow moving us abstractly “beyond” the objects our brains know about. No, the point is listening so that we preempt these thoughts. We are, in fact, expanding our mental model by experiencing the context of the complex (sonic) system in action. Sound familiar, Chaos Engineers? 😉

Try it.

Give yourself a time limit (it can be super-short, seconds or minutes), and only listen. If you are “thinking” that you’re listening, you are not listening. If you find yourself anticipating what will be heard next, you are not listening. Naming objects or recognizing things? Try not to (see “no thinking”). On the other hand, if you find yourself surprised that you could hear the fly coming long before it zips by your head, you’re on the right track.

Once I am in the zone with this (inspiration is another topic I will revisit soon), it feels like I am constantly inhaling, like I have to stop doing it because I need to exhale. It becomes so obviously visceral that it helps to link it to breathing so I don’t forget to actually inhale. You’ll hear often that a good way to calm yourself and get into a meditative attitude is to focus on your breathing, it’s a great way to ease into Listening Deeply as well.

In this fugue-like state, sounds simply… become. They are not anticipated, but emerge out of an indeterminate landscape. All sounds begin to be equalized; not in volume or strength, but with importance. They build their own relevance to each other, resonant or not, and soon an entire aural ecosystem emerges in your ears. It is an action that slows the world down and brings your brain into wonderfully abstract, unfamiliar territory where discoveries are there to accident, to where resilience be.

Making discoveries leads to building new mental models and more dimensional understanding. Having an intuition about the sequence of sounds that make up the courting pendulum of a hummingbird means it doesn’t seem as harsh than if you were surprised by its sound when not listening to all of the sounds.

The bias of what may have happened and what could occur is not as beneficial as deeper learning from all of the complex system, not just trying to interpret the loud bangs when its disturbances surprise us.

Feels a bit like an ode to carpe diem, but in perspective also shouting for discovery in experiment!

For more on Pauline Oliveros and Deep Listening, visit

Musical City Techno

Fanny’s Music, East Nashville

Cicada, cricket, grasshopper, frog. However that particular indeterminate carpet of sound occurs, it is a permanent feature of the American South. I grew up in this soup, so hearing this familiar symphony again after nearly two decades of being away felt surreal and magical.

It is the sound that framed my stay in Nashville, Music City, for three mini-conferences all held at once at the Nossi College of Art: Music City Agile, Music City Code, and Music City Data. Although tickets were sold separately, it was all mixed together, so all attendees had access to everything. I recall being initially impressed by their high-quality social media campaign, and getting to the venue the conference Crew did not disappoint.

art on the walls at Nossi

Music City Tech was well organized, well-staffed, expertly choreographed (at least from my vantage point, whatever demons they found were hidden well), and thoughtfully planned. The personal attention given to speakers made it special. The organizers were friendly, helpful, thoughtful, and courteous. Southern Hospitality was at its pinnacle here.

I would say that this all made it feel like a well-oiled, small event… except that 900 attendees and nearly 200 talks and workshops over three days isn’t exactly small. Not only that, it was the most diverse group I’ve seen yet at a tech conference, which really made me smile, as did the attention to including Music-themed talks!

I have written a few things related to my talk, The Music in Resilience (aka The Practice of Practice), so I won’t really go into it here (blog version, soon enough). Instead, what I want to embolden is this thread of confluence between musical and sociotechnical systems that I see showing up in other peoples’ thinking.

instruments on the show floor!

Before jumping into the other talks, it helps to underscore a central theme from mine that was strongly emphasized in all: being on a technology team is like being in a band. An important tool for a collaborative team to maneuver the challenges of complex systems, software or musical, is to build group intuition.

The Sounds of Software

Brett Berliner (@brettberliner)
Principal Software Engineer, Insight

Right away Brett made the connection that many people make and that I’ve heard all my life: musicians make excellent computer people and computer people love music (he has personally attended 500+ live shows). He started off by drawing a clear parallel between great team communication and people getting together as a band and practicing.

geeks geek out to the afterparty band

I felt a bit like I was lounging in a levitating gondolier, floating low above the surface, with our guide pointing out topography below of how music and coding intersected. Using himself as Exhibit A, we were shown early listening devices (boom box, portable CDs, mp3 player pioneers), logos of usual suspects in online music services (props for Bandcamp mentioned), and even headphone recommendations. He explained the methodology for choosing songs for his shared playlists, crafted for various moods and temperament while working.

Lastly was an introduction to live music coding, including something I’ve used before called ChucK, but mostly featuring a (successful!) live demo of Sonic Pi. This came before my talk on Friday, and although I normally never go to talks before I give one, I wanted to make sure I saw this because I had a feeling I could relate.

Does Your Team Groove?
What You Can Learn from a Bass Player!

David Gentry
Scrum Master, Agile Coach

A good deal of the sponsorship appeared to revolve around Agile practices and general team organization and efficiency. Part of the Agile conference track, this talk was my favorite. He even brought a copy of The Music Lesson by Victor Wooten – source material and inspiration for his subject – to give away. You know I grabbed it.

Good Groove is everything but the notes, Good Agile is everything but the process.

Right away the familiar motif returned, and “playing with other people” underlined everything, again making the astute observation that collaboration in teams is the real action of playing with people. I think he and I share the same view that this is not strictly allegorical. As such, David more strongly resonated with the subject matter of my talk, really digging into specifics, not being satisfied merely by comparison and simile.

Like I do with idiomatic improvisation and complex systems, so does David link bass playing and the Scrum Master, believing in that deep connection, feeling it himself. These relationships aren’t only useful because of being relatable to the prevalence of Music in the lives of humans, they also tickle the same cognitive space as collaboration in software engineering.

David and his bass came to play!

He covers six territories of overlap: 1) Servant Leadership as a Scrum Master is akin to the place of the bass in a band, a foundational but often not obvious carrier of the ground; 2) Congruence as the rhythm and harmony holding things together, not noticed until incorrect or missing; 3) Cadence as tempo, synchronization, pulse, and timeboxed structures; 4) Conflict as dissonance that eventually balances to illuminate resolution and discovery; 5) Space as one of the greatest things to give or receive, with characteristics of trust, self-organization, psychological safety, and freedom to innovate; 6) Groove as everything about music but the notes, or in Agile as anything except the process.

His electric bass was at the ready, playing along with simple accompaniment through a single amplifier, giving examples of each of these six in its musical context, while also showing common language used in the sociotechnical one. Triplets against dotted rhythms for Congruence and walking jazz bass for Conflict were especially good, and hey we were even ‘Journey-rolled’ once he made it all the way to Groove. Don’t stop believin’ in Agile, I guess? 😉

What is Kafka?
TicketMaster’s Data Streaming Journey

Pooja Rallabhandi (@pzralla)
Software Engineer III, TicketMaster

defunct PC store, East Nashville

What I liked about this was its connection to Music through a mature, massive, and borderless sociotechnical system that has grown in complexity over nearly half a century. After steering any hecklers away from TicketMaster’s pricing model, Pooja flew at a high level about Kafka‘s pillars, giving a brief overview of the value in persistent Commit Logs and the relationship of producers and consumers with brokers.

The T.M. Core database surely isn’t the same technology in use 43 years ago, right? Although … [queue time travel sequence soundtrack] … I fondly remember operating the TicketMaster VAX terminal at Tower Records 15 years ago, itself reminding me of the VAX at Virginia Tech we used for email 10 years before that … ok, so maybe it’s not that unbelievable. She explained that attempting to solve their problems with normal queue products like ActiveMQ simply didn’t work, ultimately choosing Kafka to front the read layer of their access model for ticketing.

Ticket order transactions go directly to T.M. Core, maybe through some other logistics prior, but nothing touches Kafka yet. That happens when the data gets aggregated and prepared for display – for example on your phone for scanning right after you bought it or for resellers, where immediate updates would be needed – and a near-real-time stream of data is required. That’s where Kafka’s speed and durability comes to the rescue, which they bolster even further with their own strong consistency guarantees by performing snapshot comparisons. It is an elegant example of the tried-and-true separation of reads and writes so familiar to efficient database usage.

afterparty jugglers and geeks converge

Philosophy vs Practice

PJ Hagerty (@aspleenic)

This one had nothing overtly to do with Music but neatly supports our central theme. The reason I wanted to check this out was not only that PJ was basically the one other speaker there I even remotely knew, not because he recommends the CI/CD tool I have most recently experienced (GoCD), not due to his self-proclaimed musicianship (I’m sure he’s a fine singing saw player), not even because he called out Chaos Engineering with a Netflix tale, but because the general topic touches an exposed nerve of mine.

The key is that teams work together, the most important part of DevOps is communication.

Nevertheless, his presentation attempted to move us away from the catchphrases so often associated with DevOps, instead dialing-in on how modern tooling supports a cross-disciplined cooperative environment. I am particularly interested in this perspective because Chaos Engineering plugs directly into concepts of group learning in a sociotechnical complex system, especially Game Days (outlined in my talk as ‘The Practice of Practice’).

He also gave a shout-out to another sociotechnical subject near and dear to my heart: SRE. Only he called it Site Reliability Expert. I think my tweet on this sums it up nicely:

This ‘mistake’ actually fit into the talk perfectly, because eschewing the buzzwords really helped make it all about practical combinations of tool and theory, and PJ readily handed out toolset recommendations by continuously relating their practicality to the overreaching philosophy of DevOps.

What is that philosophy, you ask? It’s pretty simple, and it was refreshing to hear someone else say so. Above all, the key is that teams work together. The most important part of DevOps is communication. In fact, it makes sense to think about DevOps as something that needs multiple perspectives to exist at all. Maybe DevOps is everything about software engineering except the code.

Music City

The Gambling Stick BBQ

It felt good spreading the word of Chaos Engineering and Resilience to more ears, and it was spectacular to be a part of the conference. Having been at a few conferences lately that happen on the (US) coasts, it is striking that trends and conversations around the resilience of complex systems and new ways of thinking about safety aren’t being as heavily preached in more landlocked locales. At both here and Texas Linux Fest earlier this year, the number of hands going up for the question “who has heard of Chaos Engineering” was one or less, even in casual conversations. I am finding that this subject seems to get a lot less attention in so-called ‘flyover’ areas than it would at a coastal conference. This needs to change, and my team at Verica is in the game to help make that happen.

I decided to stay over in Nashville a bit afterward to experience some of the city (and sorely missed southern BBQ), fortunate to have a friend and coworker there with whom I also wanted to spend time. So imagine my joy when she surprised me on Saturday with a message that “Duet for Theremin and Lap Steel” from Atlanta (@duetonline) would be performing that night at a sake distillery downtown.

Of course, without a moment’s hesitation, I said yes.

DFTALS at Proper Sake, Nashville

Welcome to the Verified Machine

Imagine for a moment that you’re a software team, pushing new versions into production. You’re working on multiple pieces independently, so as you make changes automation pulls it all together in orderly Continuous Integration. At the right moment, your team’s work is pushed and Continuous Delivery does the job. Five deploys a day? No problem. Y’all have written, collaborated, tested, and published your glorious stuff. Job well done!!!

Just kidding, you’re not done. Does anyone write software that will suddenly just stop? Ok, maybe Y2K mitigation. But most of us in this industry want to see our stuff keep running into the unforeseeable future. That’s where Continuous Verification enters the picture. In operations, we’ve been given the ball to ensure the reliability of the software you write, but we want to be as invested in running it into the future as you are in writing it.

So, long story short (and trust me it’s long), that’s what I’m doing now at a company called Verica. We are a Continuous Verification company. It’s an area closely aligned with Human Factors Engineering, Resilience Engineering, Safety, and Chaos Engineering. In fact, Chaos Engineering is central to what we do. We are here to help the enterprise get a leg up on Continuous Verification for the complex distributed systems they run. Tested in production, like the glass says.

At Verica, I’m still doing ops. I am SRE, I am Sr. Infrastructure Engineer, I am IT, I am NetEng, I am Purchasing, I am UAT. When we get some, I’ll be DataOps. Nevertheless, I’m beginning to traverse a lot more of the software stack than I ever have before (Golang and service meshes, reluctantly Python, you can rip my Zsh from my cold dead hands). I am excited to teach and speak and collaborate on all things Chaos Engineering, especially how it intersects with my musical proclivities. I will be speaking at Texas Linux Fest at the end of May about this very topic!

Most of all I’m excited to work with a stellar team. These are people I’ve changed up my life and taken great risks to work beside. Five years ago I discovered there was a close similarity between indeterminacy in distributed systems and the things I have studied in music. Verica is the next amalgamation of my love for musical improvisation and operating complex systems. It’s about time I wrote an opera, isn’t it?


Plenty of people who work in technology are musicians. Plenty of humans are musicians, and all of us are listening, even those who cannot hear. In my travels through datacenters and software, I have come across musicians like myself who have not only done double-duty with their computer science and creative lives but also relate and interweave them. If they’re like me, they cannot break them apart. There are hundreds, if not thousands, of us. We all have different stories, came into the worlds of music and of technology from different angles and different backgrounds.

I’ll hazard a guess that when you think about the words music and technology together, it’s likely you’re thinking about music technology. This isn’t surprising, a great deal of music technology surrounds the production, performance, and recording of music. Musical Instrument Digital Interface (MIDI), studio recording, guitar pedals, analog control voltage synthesizers, DJ decks, Ableton Live, Max/MSP, Joe Armstrong running Erlang on Sonic Pi… the list goes on and gets fractally esoteric. All great examples of technology facilitating the art of music, but I’m interested in what’s happening the other way around.

The original impetus for this post was a comment someone made that raised an eyebrow… it made me briefly question the ideas I have about the field of resilience in distributed systems somehow relating to music. But humans share such an indisputably organic relationship with music and musical training that I knew I wasn’t just some crazy person, the connection was there and it was real. How else do I have the job I have now? This pushed me to want to find others that share my views on the close relationship music has with software and operational reliability.

Take Chloe Condon (Dev Advocate at Microsoft), a self-described recovering musical theatre actress. Now, my musical theatre training and tastes are preeetty specific, but I can relate. She pulls her theatre training into her work unforgivingly, and that is awesome because I fear that. Inspiringly passionate about the connections between her performing arts expertise and working in tech.

Recently chatting with her at SCaLE, Chloe clued me in about someone close to my wheelhouse: “Opera Singer turned Software Engineer” Catherine Meyers. Her Mozart could’ve been an Engineer talk correlates music theory and counterpoint to building software. She emphasizes the similarities of pattern recognition between the two disciplines, especially as it relates to learning. Preparing a new piece or constructing a score interpretation is 100% relatable to the software engineer learning a new language or building in a new framework. I especially love how she emphasizes the importance of having different types of minds together in one group, in other words, don’t be afraid to hire a music major.

These folks that are trained in synchronizing common ground through the experience of playing in musical ensembles carry a distinct advantage. Diversity and communication are the trademarks of both successful musical groups and software teams. Establishing common ground through shared learning is crucial to the modern team building and operating distributed software. It is obvious to me that ensemble music not only relates to complex systems but also to highly coordinated teamwork, to wit:

I’ve conducted marching bands, wind ensembles, and jazz bands... They are complex, highly interdependent systems.

Tanner Lund (SRE at Azure)

This couldn’t be more true! I have been in an experimental vocal trio, a free improv quintet, a blues band, a jazz group, an early music ensemble, a 330 piece marching band, uncountable operas with full orchestra and cast, chorales of few to many, piano accompanists by the dozen. There is nothing in any of these situations that doesn’t require common ground and shared experience.

In her blog post, The Origins of Opera and the Future of Programming, Jessica Kerr (Lead Engineer at Atomist) introduces the concept of symmathesy, a state of collaboration that is integrated with learning, all as part of the system (even the tools are team members). She does so by taking us back to the foundations of modern opera in Italy, adeptly adopting the term ‘camerata‘ from the Florentine Camerata example she uses, applying it next to social circles of painters and artists in later centuries, and then to teams creating software. She considers how our mental models evolve and how common ground is reached through the shared experience of a varicolored team from all sorts of different backgrounds, ultimately making the team more powerful. “We are developing whole new ways of being human together” she states, and to me, that’s nowhere more clear than with multi-disciplinary collaboration.

The CS / Math / Music crossover is clearly one I have encountered a lot, from early on. While I was studying voice and music technology in undergrad, I vividly remember walking with a good friend in downtown Blacksburg, and her saying to me “I could never major in music, there’s too much math.” I used to laugh at this because there’s really only as much math as that you wish to encounter. Want to dive into tempered tuning and Kepler’s mathematical ratios for perfect fifths? Go for it. But you know, these days I look at that statement through different lenses. Yes, there is just enough math! And if you study music, you may run the risk of studying computer sciences. * Please be aware that some practitioners of both have reported sudden bouts of inspiration and lightheadedness due to euphoric discoveries that cross disciplines.

On the subject of cross-discipline study…

I find a lot of what of I learned in music performance transfers directly to public speaking.

Amy Tobey (SRE at GitHub)

As a student of opera, I couldn’t agree more. Long ago I had a theatre teacher tell me “you will never be happy not onstage.” I didn’t know what she meant until I myself experienced exactly the same kinds of challenges and rewards with giving talks and public speaking as I did singing Mozart or Fauré in front of large audiences. I discovered that my experiences onstage presenting music are exactly the same headspace as when I’m talking in front of a room of computer people about distributed systems.

When I gave my talk Measuring Distributed Databases Across the Globe at Southern California Linux Expo 13x (2015), a very enthusiastic artiste-cum-techie approached me afterward. They had decided to move into software engineering after art school and said my talk, which combines theories and ideas in music with those of observing and operating huge distributed databases, was inspiring. They had been trying to reconcile their internal ‘artistic identity and self’ with their passion for coding, and I had opened their eyes to a new way of considering it.

I will never forget this. It was exactly like having someone come up after one of my experimental music performances (which are also heavy with technology) being blown away and asking how things worked. Even if one mind out of a thousand is influenced by what I’m doing, whether it’s music or technology, I’m building the camerata through sharing.

Eureka! The audience contributes to symmathesy, too. There are tons of examples; the feedback of a crowd during a DJ set, participants of David Tudor’s Rainforest, someone opening a candy wrapper at the symphony. There’s no getting away from the audience, however small. John Cage preached throughout his career as an avant-garde composer: listeners are participants. Every performance is something new because there are different people in different places every single time. The title of this piece is a play on Cage’s Musicircus, an amalgamation of disciplines and performers occupying the same large space together with the audience.

So consider the sheer experience of music and how it feels oddly in-step with how we think about technology, and take it one step further. Many of us trained in the practice of music consider it so much a part of our bones that it seeps into our work, we don’t have a choice, the pattern recognition pathways seem to match up. They fit into our psyches in a comfortable way, share the same affinity for abstractions, incorporate complex and overlapping systems that stretch the human capacity for comprehension.

Do I have an aptitude for music because I’m successful in understanding the practical application of complex things? Or do I have an aptitude in technical operations because I have been trained in music and theatre arts? Doesn’t it make sense that the diversity of music is a human quality, not a disciplinary one? Why should our work as computer scientists, software engineers, database operators, and network gurus be any different?

Temple Grandin talks about the world needing all kinds of minds. In her view, different people fall amongst three “categories” of thought: Picture (common on the autistic spectrum), Pattern (code, math, music), and Verbal (writers). It resonates with me a great deal because I always feel like I’m thinking in ways others are not. More specifically, though, it underlines how different styles of thinking can bring entirely new perspectives on a particular question, and how crucial diversity is to human endeavor, if not evolution itself.

This post started out as me being passionate about a subject and wanting to search for others who were. I had some bullet points of my own to insert, but as I searched and connected with others in the field, I learned new things and this blog transformed from a list of Twitter handles to real human relationships. I have grown to understand what Kerr means when she says that ideas are for sharing and collaboration, not hoarding and heroism. I for one am claiming my spot in the camerata that pushes us forward through a New Renaissance.

Weirdness of Experiment

My job in ops has always been to keep things running. I never considered myself “working in software”, but have recently begun embracing the fact that I do. What I accomplish as an operations and infrastructure engineer is part of the system, it isn’t dislocated from its composition.

Relatedly, I have been considering the nature of the experiment in Chaos Engineering. How continuous verification is becoming a crucial part of the complex systems we build because there really is no end. Developing a software system isn’t just about writing it, it’s also every bit as much about running it. Unless there is some kind of evil catastrophic end-game planned from a volcano island hideout, most of us want to keep them running.

I’m big on experimental music. You probably know what I mean when I say that, but you might not because genres, in general, are horrible overgeneralizations. Similarly, after the composer John Cage had written his “silent piece” in 1952 (see also Living 4’33”), he seemed to have a struggle with the concept of calling the music composed by him and others he admired experimental.

In science, we often think of an experiment as a method to (dis)prove a hypothesis. We perform experiments to answer a question or assertion, often during the process of reaching an end goal. To Cage, this implied that calling something an “experiment” meant it was not complete, not finished. That there is a final state determined by products of the experimentation, and he thought that his (and others’) music was complete when performed. There was no “final state” that was decided as a result of an experiment either succeeding or failing, if it was itself called experimental.

Cage revised this view, however. He began embracing the term and actually ended up preferring it. The reason for this is the way he evolved to think about the context of sound. At the beginning of the decade, he experienced an anechoic chamber (an “echoless” room) and the non-presence of total silence, because he could hear both high and low sounds — explained to him by the engineer as his nervous system in operation and blood circulating, respectively. Whether or not that is physiologically probable, he had the now famous revelation that it is impossible to remove sound completely. 4’33” and an entire philosophy about the nature of sound and silence in music was not far behind.

To him then, the moniker experimental came to mean that which is undiscovered, because even if a piece of music requires certain sounds, environmental sounds are impossible to predict. This experimental music isn’t about the search for failure or success, but an experience of discovery, where questions become more interesting than answers. When applied to composition, each performance of a musical work is always new and different due to its context and sonic environment. Indeed, it is impossible to know ahead of time any structure of the interpenetrating sounds both intentional and not, themselves independent and unique (whether or not they are consonant). It is in fact in a total state of chaos, each and every time.

When complex systems run, they do so at the hand of indeterminacy and randomness. There certainly is a “steady state”, but it is continuously in need of verification. Just like Cage observing that no performance of a musical work is a repeat, the nature (structure and form) of distributed systems we operate cannot in truth be predicted with any kind of regularity.

So while it is useful to be very specific in defining and running our Chaos experiments, the nature of what we’re doing is more about asking questions and making discoveries, not testing for answers we already think we know or think we can guess. The “breaking things in production” mantra implies we are interested in failure when what we’re really interested in is what was determined and what questions arose, good or bad.


Here are a couple of PDFs taken from Cage’s writing that highlight his viewpoint on the subject of “experimental music” as a title of what he did.

  • Experimental Music: Doctrine (1955) ::: This article, there titled Experimental Music, first appeared in The Score and I. M. A. Magazine, London, issue of June 1955. The inclusion of a dialogue between an uncompromising teacher and an unenlightened student, and the addition of the word ”doctrine” to the original title, are references to the Huang-Po Doctrine of Universal Mind.
  • Experimental Music (1957) ::: The following statement was given as an address to the convention of the Music Teachers National Association in Chicago in the winter of 1957. It was printed in the brochure accompanying George Avakian’s recording of my twenty-five-year retrospective concert at Town Hall, New York, in 1958.

The photo above is the album cover from a release by Craque called Meat Hacker.