Skip to main content

craft and discipline, larks' tongues in aspic

One of my lightning talks at AWTA had to do with finding better languages than engineering and manufacturing with which to describe software.

With all due respect to the Leaners, if software work were like factory work, few of us would do it.

I suggest we look to art, literature, and especially music for language to talk about software.

I mentioned first a couple of academic examples taken from New Criticism and Structuralism, like Monroe Beardsley's idea that value is based on manifest criteria like unity, variety, and intensity, or the Structuralists' idea that value is based on the degree to which the work reflects the folklore and culture of the milieu where it was produced.

If they'd done software, Beardsley would have been analyzing coding standards and function points, while the Structuralists would have been all strict CMM or strict Scrum/XP. If you're a objective-measurements, CMM, or Agile person, I encourage you to find corollary principles in the language of art and literature.

But the language that really got a lot of interest at AWTA was my super-fast overview of Robert Fripp's ideas of guitar craft. (If you don't know Robert Fripp from his work with the band King Crimson, you might know him as the composer of all of the new sounds in Windows Vista.)

I wanted to find and cite some short examples of his work here, hoping the discussion would continue around Fripp's language based in musical practice.

There are any number of fine software practioners discussing software craft, but it's often a linear discussion. I have yet to run across much discussion of how to acquire, reinforce, and advance software craft. People agree it should be done, but when we discuss the details, there is much waving of hands.

Fripp, on the other hand, has at hand a rich, intellectually rigorous, logically consistent language, with a 20-year history of exercise and teaching, describing the practice of guitar craft that is fully prepared to inform our discussion of software craft.

The key is discipline.

Here is the beginning of "A Preface to Guitar Craft". As you read it, substitute "programmer" for "musician" and "software" for music:

The musician acquires craft in order to operate in the world. It is the patterning of information, function and feeling which brings together the world of music and sound, and enables the musician to perform to an audience. These patterns can be expressed in a series of instructions, manuals, techniques and principles of working.

This is the visible side of craft, and prepares the musician for performance. It is generally referred to as technique. The greater the technique, the less it is apparent.

When the invisible side of music craft presents itself, the apprentice sees directly for themself what is actually involved within the act of music, and their concern for technique per se is placed in perspective.

The invisible side of craftsmanship is how we conduct ourselves within the process of acquiring craft, and how we act on behalf of the creative impulse expressing itself through music. In time, this becomes a personal discipline. With discipline, we are able to make choices and act upon them. That is, we become effectual in music.

or this:

These are ten important principles for the practice of craft:

Act from principle.
Begin where you are.
Define your aim simply, clearly, briefly.
Establish the possible and move gradually towards the impossible.
Exercise commitment, and all the rules change.
Honor necessity.Honor sufficiency.
Offer no violence.
Suffer cheerfully.
Take our work seriously, but not solemnly.

Or this from an interview on

Guitar craft is a discipline; the discipline is the way of craft.
This is the part that is missing from the discussion of software craft: the discipline. It's something I'll be working on.


Dave Hoover said…
I'll need to look deeper into Fripp's work. As I was doing research for my writings on software craftsmanship and apprentices, I read "Zen Guitar" and had this to say about it. I certainly think you're onto something here, Chris.

Popular posts from this blog

Reviewing "Context Driven Approach to Automation in Testing"

I recently had occasion to read the "Context Driven Approach to Automation in Testing". As a professional software tester with extensive experience in test automation at the user interface (both UI and API) for the last decade or more for organizations such as Thoughtworks, Wikipedia, Salesforce, and others, I found it a nostalgic mixture of FUD (Fear, Uncertainty, Doubt), propaganda, ignorance and obfuscation. 

It was weirdly nostalgic for me: take away the obfuscatory modern propaganda terminology and it could be an artifact directly out of the test automation landscape circa 1998 when vendors, in the absence of any competition, foisted broken tools like WinRunner and SilkTest on gullible customers, when Open Source was exotic, when the World Wide Web was novel. Times have changed since 1998, but the CDT approach to test automation has not changed with it. I'd like to point out the deficiencies in this document as a warning to people who might be tempted to take it se…

Watir is What You Use Instead When Local Conditions Make Automated Browser Testing Otherwise Difficult.

I spent last weekend in Toronto talking to Titus Fortner, Jeff "Cheezy" Morgan, Bret Pettichord, and a number of other experts involved with the Watir project. There are a few things you should know:

The primary audience and target user group for Watir is people who use programming languages other than Ruby, and also people who do little or no programming at all. Let's say that again:

The most important audience for Watir is not Ruby programmers 
Let's talk about "local conditions":

it may be that the language in which you work does not support Selenium
I have been involved with Watir since the very beginning, but I started using modern Watir with the Wikimedia Foundation to test Wikipedia software. The main language of Wikipedia is PHP, in which Selenium is not fully supported, and in which automated testing in general is difficult. Watir/Ruby was a great choice to do browser testing.  At the time we started the project, there were no selenium bindings for …

Open letter to the Association for Software Testing

To the Association for Software Testing:

Considering the discussion in the software testing community with regard to my blog post "Test is a Ghetto", I ask the Board of the AST  to release a statement regarding the relationship of the AST with Keith Klain and Per Scholas, particularly in regard to the lawsuit for fraud filed by Doran Jones (PDF download link) .

The AST has a Code of Ethics  and I also ask the AST Board to release a public statement on whether the AST would consider creating an Ethics Committee similar to, or as a part of the recently created Committee on Standards and Professional Practices.

The yearly election for the Board of the AST happens in just a few weeks, and I hope that the candidates for the Board and the voting members of the Association for Software Testing will consider these requests with the gravity they deserve.