Some years ago, when I was completing a PhD in music theory, a friend observed to me that composers have methods, techniques, processes to help them do things that don’t come naturally or easily to them. This (so to speak) struck a chord, and it’s true in many ways in software development.

To dig a little further: in the twentieth century, for a variety of reasons which fill a book in themselves[1], composers moved into academe, and as part of their teaching started writing down what they did. Schoenberg’s methodologising of his compositional practice - twelve-note or serial composition - was aped by a generation of composers, some of whom made it their own, but some of whom simply played by the rules. It’s notable that those who were directly exposed to his teaching over many years - notably Alban Berg and Anton Webern - developed their own unique accommodations with this technique, in ways which are hugely expressive of their own personal styles (indeed, even if you’ve never heard a note of their music, I think you can make a guess at their respective styles and aesthetics simply by looking at photographs of the two).

This points to two problems with writing things down. Firstly, generally people only write down what they’ve constructed, which is, as we’ve seen, only ever a skeleton expression of the things that don’t come naturally. And secondly, once these things are written down, we as readers assume that it’s all that you need to do. This is true whether the author actually believes that, or even when they explicitly state it’s not the whole story: no amount of caveats will prevent an outline of a method turning into a brand, or a religion, if it has the right hooks, touches the right nerves, appears to answer the important questions of the day, or is taken up by egos with agendas to serve.

It bears repeating that software developers are no more immune to this than would-be composers. In the many “death of agile” blogs, essays and articles, I see lots of people writing off Scrum, XP or the other agile methods for their perceived failures to solve some the pressing problems of development in teams and organisations: while you can (and I do) take exception to the way some individuals and groups market these ideas (and don’t get me started on the Agile Manifesto…) it’s misguided to blame them for not giving the whole picture: method can never do this.

Wittgenstein talks about “throwing away the ladder” of method:

…anyone who understands me eventually recognises [my propositions] as nonsensical, when he has used them - as steps - to climb up beyond them. (He must, so to speak, throw away the ladder after he has climbed up it) [Tractatus, 6.54]

Here method, as a set of propositions and elucidations, is used as an educational tool, to develop practice and hone consciousness. We focus on the ladder, rather than the princess in the tower…

Kent Beck once said that all methodologies are based on fear. Fear creates stress, and being in stress is no condition in which to do our best work. I like the notion from Improv, that we do our best work when we’re in the right state: let’s get away from obsessing about Scrum vs Lean vs Kanban vs whatever, look at what we’re trying to achieve, regard any way of working as transitory and contingent, and work on improving each others’ experiences of development, of our teams and organisations.

[1] A great start is Alex Ross, The Rest is Noise. But of course, you can (and should) check out the music of Berg and Webern on Spotify…