Software Anti-craftsmanship

Today was the February installment of the Salt Lake Agile Roundtable (#slagile). Originally founded by Alistair Cockburn way back in the mists of time, it persist to this day as a place for some of the best conversations surrounding Agile that you can find anywhere.

If you've never been I'd highly recommend taking in at least one of the meetings. In past meetings there has been all sorts of interesting shenanigans, everything from the obliteration of hopeful doctoral dissertations to actual coloring sessions with crayons and everything (no, I'm not making that last one up - you had to be there)

One of the key elements of the meeting structure is that everyone is asked to bring a topic for discussion. Ideally it will be related to a challenge you are facing but with some of us old timers who've heard just about every kind of problem with software teams you can come up with we have a tendency to introduce topics that will provoke (hopefully) interesting discussions.

Or at least interesting arguments.

My topic today was inspired by a comment someone had made in a previous topic. What they said was "Well, yes, but a craftsman (software) would never do that". Waving an absolute like that in front of us has roughly the same effect that catnip does on cats, so of course I had to find out from the group exactly what they thought software craftsman ship was.

Thus I asked the question: "Exactly what does it mean to be a software craftsman? How can you detect the spoor of such an elusive beast?"

 OK. Maybe I didn't use the term "spoor", but I should have. Would have given me a good excuse to break out a pith helmet in the middle of the meeting.

Of course it wouldn't be the Salt Lake Agile Roundtable if there wasn't a twist to the conversation. The twist of the day was provided by David Adsit (@davidadsit) of Pluralsight. David decided to take the contrarian view and present his list of really annoying things that those craftsmanship jerks do.

Without further ado, I give you David's list of "Software Anti-craftsmanship" qualities:

1. Wastes far too much time navel gazing
2. Pointlessly delays the deliver of "good enough" code

3. Constanty renaming everything! Always with the renaming!

4. Fritters away valuable time changing existing code rather than working on new code

5. Treats the rest of us like second-class programmers

6. Constantly taking off for yet more useless training. Don't even get me started about all of these "Retreats"!

7. Imposes their philosophy about why the way they work is better without ever offering any actual evidence.

You know, I think we might have the beginnings of a manifesto on our hands here...

Jammin'

Last night I had the pleasure of participating in a "Jazz Dialog" event conceived and hosted by Alistair Cockburn. For those that are having a hard time seeing what those two things have to do with each other, I'll attempt to 'splain.

One of the key principles of Jazz music is the element of improvisation. No two recitations of a song played by the same players will be exactly the same because the players are not just engaged in playing the song, they are also engaged in playing with each other. It is this element of improvisation that keeps Jazz music fresh and interesting for players and listeners alike.

Imagine that you are in the audience of an impromptu Jazz jam session that has the likes of Miles Davis or Dizzy Gillespie sitting in with the group. If you are a neophyte Jazz aficionado, you may feel shifts in your emotional reaction to the music, but not really know why or how it is happening. A more seasoned Jazz fan may notice that there is some sort of interplay above or below the level of the actual music between the players, but may not be able to interpret how that interplay is affecting the evolution of the song. 

To truly understand the forces shaping the music, you'd need an expert observer who is paying attention to the players, and not the music. They would notice that Dizzy seemed a bit more subdued than usual at the outset of the song and watched Miles repeatedly challenge Dizzy to step up his energy level by intentionally magnifying his own play. Without this expert observation of the interaction of the players you may notice that the song started out slow and then picked up energy as it went on without ever realizing that it was the direct result of the interplay of the players above and below the music.

So what does that have to do with dialog? I'm glad you asked. 

For over a decade now a group has been meeting in Salt Lake on a monthly basis to talk about software. The group was originally focused on discussing Object Oriented software development, but around the time I showed up in 2002 the charter of the group had shifted to discussion of all things Agile (and agile) related. Attendance to the group fluctuates, but there is a core group of attendees that keep coming back to sit in on these conversations. 

Why? After 10 years, you'd think we'd be all talked out. But yet we keep coming back because the monthly discussion aren't just a discussion, they are our "Jazz Dialog" jam sessions. And much like a good jam session, we can take the same old tunes (such as "estimation accuracy") which seem to be in an advanced state of expired equine violence (beating a dead… you get the point) and still getting something new out of the conversation.

Because it isn't the topic that is important, it is the dance of the dialog.

I had an "Aha" from the Jazz Dialog last night - it was about the implications of our roundtable "jam sessions". Three in particular stood out to me:

1) The people that keep coming back to the roundtable sessions over the years? Dialog Jazz musicians. We all love a good jam.

2) I believe that the people that come to the roundtable looking for answers to questions or challenges tend to not stick around because they subconsciously (or consciously) pick up on the fact that the dialog itself is more important than the outcome of individual discussions and thus look elsewhere for help.

3) Multiple attempts to export the roundtable to other locations have failed over the years because they duplicate the format but not the musicians.

Of course one good "aha" leads to another, so my second is that there is an inverse correlation to the amount of interest you have in a particular topic versus your ability to look past the topic to observe the flow of the dialog. I don't think I'd be satisfied with just committing to metering my engagement with a topic in order to observe the dialog, so this means that I need to practice getting better at tracking a dialog while I'm in the middle of it.