Thursday, February 6, 2014

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...