Many years ago I read an interview with Pat Metheny in which the interviewer asked him about how he approaches practicing scales. This is from memory from a long time ago, so forgive any misquotes (and if anyone can help me find the text of the interview I’ll be glad to update this post), but he responded with something like “Scales are an important part of improvising and there are elements of scales in everything we play. But practicing scales by themselves isn’t that interesting. Why would you want to play a scale when you could be playing a tune?”

I’ve heard other musicians talk about this in terms of “if you practice scales you’ll play scales on the gig”. I believe this to be true, and can be found manifested in the music of many who like to call themselves jazz musicians.

That always resonated with me as an aspiring musician, and has manifested itself within my sensibilities about software as craft. This relates to why I’ve latched on to BDD and the surrounding conversation.

Focusing on internal state and structure in your tests is like practicing scales. The end result is often code that is clean in a vacuum, but doesn’t express its intent well – just like hearing that guitar player running scales up and down (again). It may use the most theoretically efficient techniques, but it fails to tell a story.

Focusing on observable behaviour in your tests is like practicing melodies. The result is that your code is more likely to express its intent. It’s more likely to be just the right code for that particular requirement. Just like the improvisor who always plays exactly the right thing for that moment.