In Ancient Greek mythology, the Muses were goddesses who ruled over the arts and sciences. Although their mythology changed, a common retelling has them being the daughters of Zeus and the titan Mnemosyne. Being daughters of Zeus no doubt signified the importance ancient Greek culture placed on poetry, performance art and the sciences. Mnemosyne was the personification of memory which mattered greatly for preserving those elements of culture in a time of no books.
What if software development had been around in the times of classical Greece? Would it have been considered to be some form of art or maybe as it was when I studied it, a science. If it is neither, what is it and what difference does it make to those that practice it?
When you look at this menagerie there is no mention of a maker’s muse. To the Greeks the art in making was something different. The Muses embodied knowledge and the performing arts. These “Music” arts were associated with ritual and festival.The physical arts, the plastic arts as Johan Huizinga calls them, were seen as something other. He suggests the difference is that “Music” arts have the element of play because of their need to be performed. In some cases they also had the element of agon or competition in their performance. Even the Epic and History were intended to be recited as part of reinforcing cultural memory. The action of performance to Huizinga placed them in the play-sphere.
On the other hand, the plastic arts lack the same element of play as they focus their efforts on the material being formed and the action of the forming. Artists and makers do inject an aesthetic into their creation which can be appreciated by the observer. It is that later emotional connection and interpretation of a piece that the artist regains some place in the sphere of play.
Working with software development teams I find this distinction holds true and helps guide me in where I think the seeds of a software delivery oriented culture might sprout. When I say team, I mean the amalgamation of all roles. Their artwork being anything from stories to code to tests in whatever form they manifest themselves. Delivery could be seen as molding a knowledge of needs in code. Once created the observer can appreciate the product through its demonstration and in so doing assert whether the need was met. The original inspiration that led to the transformation of knowledge regains its play element. Much as a “Music” art is retold or performed so the product is reused in some part of life that sits in the play-sphere.
A team itself may be committed to crafting but that does not preclude an agonistic element. In the best developers I have worked with, there is an urge to strive and to challenge each other. However it is not in a manner that creates ornamentation in their code but more mastery of their craft. It is more about reveling in the fit and finish. It is about the intrinsic quality only they will ever see than trying to outperform each other by making a more impossible puzzle to maintain.
This spirit flourished in the medieval guilds in the form of technical competitions by which guild members made the rite of passage to master craftsman. The initiations, the societies and emblems that differentiated the initiated helped to identify the communitas of the masters.
I see these notion of craftsmanship as a rich element to build a delivery culture around. However I think it a shame to aspire to drain play elements from that culture. I have tried to experiment with commingling craft and play in the hope that I can help bring an opportunity for teams to make their work both joyful and serious.
Birth of a Build Monitor
The inspiration for this has been the seemingly dry well of continuous integration. Even in the dull automaton that is the reliable build server you can find a hidden source of play. During my first encounter with Agile, I happened to be near some developers who looking at Cruise Control documentation and wondering about build monitors. Devices that could be turned on or off with the success or failure of builds. They happened to be talking about the X-10 devices which at the time where a cheap way to control mains power. The X-10 devices could be controlled via a serial dongle by Cruise Control. What you did with control was up to you. Lava lamps were popular. I may have been a project manager to be ignored by them but I was and will always be a maker at heart. I had gobs of X-10 devices and suddenly it was me begging them to try it out. After some initial experiments we had the plugin configured and I went about building a device. Because of the spread out nature of the office, my first device consisted of flood lights projecting onto the ceiling. Red for compile failure, blue for test failure and green for all tests passing.
The device immediately began to change the behavior of the team. By projecting build failure for all to see a competitive element crept into considerations of quality. Simple things such as developers starting to proactively communicate if some common library was changing so there would be no condemnation as dependent modules initially failed until the updates rippled through the code.
Over time, driven by my desire to feel more connected to the craft and creation, my build monitors have grown in whimsy and so as a tool for play. In the next few posts I’ll talk about the most recent incarnation. I’ll look at how we have build an element of play into Quality and the things we learned but had not expected to.