Real live music

“Yes,” said Golg. “I have heard of those little scratches in the crust that you Topdwellers call mines. But that’s where you get dead gold, dead silver, dead gems. Down in Bism we have them alive and growing. There I’ll pick you bunches of rubies that you can eat and squeeze out a cupful of diamond juice. You won’t care much about fingering the cold, dead treasures of your shallow mines after you have tasted the live ones in Bism.”

- C. S. Lewis, The Silver Chair

I am fascinated by our collective fascination with live music. Why does it make a difference whether we access a piece of music through the thick dark air of a crowded pub or via a commercial recording and distribution process?

I question the mechanism, but I have no doubt as to the potency of its effect. I revel in live performance. I even listen to live albums - which I simultaneously find conceptually daft and utterly compelling.

My own pet theory is that liveness (life?) is a perception of the possibility of being otherwise. As each note is struck, plucked or sung, the audience knows that though the piece may be written a certain way, in a live rendition it ain't necessarily so. Any given note has the potential to be substituted, varied or flubbed.

But once a note has transformed from a musical intention into a perturbation of air and propagated through the room at (approximately) 340.29 metres per second, it drops down dead to the floor. The high note has been hit, or not. The high hat has been hit, or not. The blue note has been blown and the possibility of being otherwise has ceased.

Music-as-code offers a variation on this theme. If I, for example, describe my music with Clojure and Overtone, then I can render my music to my speakers. But I can also alter it at will. If I take care to directly represent the deep structure of my music in code, then I can easily make changes to instrumentation/tempo/swing that even editors and sequencers of binary sound files cannot.

I can bring the power of iteration, of version control, of collective review, of unit testing, of my combined past and present selves, to bear on a piece of music. The possibility of being otherwise is preserved.

Music created with Overtone isn't just live - in a sense it's immortal. What's more, we now have the perfect retort to the unkind critic - "Pull requests accepted".

Chomsky on static typing

Colorless green ideas sleep furiously.

- Noam Chomsky, Syntactic Structures

Goldilocks services

Github is a document store. Each repository is a document. Transactions are easy to execute within a

document and only eventually consistent across documents.

If your documents are too large, the scope of your transactions will be excessive, and you will get contention. If your documents are too small, the scope of your transactions will be insufficient, and you will be forced to manage changes across multiple transactions.

Each service is an aggregate root, so design them so that they can be evolved independently. 

Second order poka-yoke

Poka-yoke is the practice of "mistake-proofing" - designing interfaces in ways that prevent users from making mistakes.

Continuous integration is a form of poka-yoke for software development. Developers are prevented from releasing (obviously) broken software to production by a battery of tests.

However, poka-yoke is about designing to mitigate specific user mistakes (at least as I understand Shingo's definition). In other words, it's about putting up safety barriers between users and anticipated failure modes.

How much better to develop in a software ecosystem that discourages not only the occurrence of mistakes, but encourages the growth of designs that do not admit the possibility of these mistakes.

My colleague Gurpreet Luthra cites the example of making heat-resistant bolts a different size to ordinary ones so that they cannot be accidentally interchanged. However, were the design to be simplified so that the engine was a single piece of metal, bolts would not be required at all.

Sometimes simplification is possible. Other times essential elements of the domain force us to introduce scope for error. Perhaps engines could be constructed differently to simplify assembly. Perhaps not. The only way to tell the difference is to be constantly vigilant for the possibility of eliminating accidental complexity.

Having thorough test coverage is good. Preventing the complexity that disrupts developers' ability to comprehend the system well enough to avoid mistakes is better.

Simple designs can not only make mistakes avoidable, they can make them literally inconceivable. By that construction, you could consider a disciplined pursuit of simplicity second-order poka-yoke.

Fixation and variability

While explaining Why Everyone (Eventually) Hates (or Leaves) Maven, Neal Ford divides extensible software into two categories: composable and contextual.

Contextual software is best exemplified by plugin architectures - new features are added by slotting code into explicitly provided extension points. Composable software is best exemplified by the Unix ecosystem - new features are added by wiring together a combination of existing and custom components.

So what is it about contextual systems that provokes such hatred?

The key problem when making software extensible is where to put the variability. I have a fixed set of core features, but I also want others to contribute extra features that vary depending on their needs. How do I bind the fixed and variable functionality together so that they form a coherent system?

Maven accommodates variability like a classic contextual system. The promise (and the curse) of Maven is the consistency of its build lifecycle. There is a place for everything, and everything must be in its place. Maven affords very little flexibility on the relationship between variable additions and its fixed feature set.

Rake, on the other hand, empowers developers by allowing extension via a general purpose programming language. Rake qualifies as a composable system because any means of adding new functionality that can be expressed in Ruby can be used to extend it.

In composable systems, orchestration is variable. In contextual systems, orchestration is fixed. Keeping the means of combination in userland is an additional burden on those who would extend your system, but it's more than offset by the flexibility and power they enjoy in the long term.

Your software will grow, but your relationship with Maven won't. If When that happens, it's time to leave.