Brief Thoughts on Software Craftsmanship

To catch people up on some blogosphere drama:

Last month, Heather Arthur posted on her blog about an unfortunate incident in which some people on Twitter had found some code she wrote in GitHub, and people started trashing her on Twitter for it. Some of those people are considered leaders in the Software Craftsmanship movement, in particular Corey Haines. Corey immediately apologized for acting like an asshole, and I think his apology was sincere because I’ve met Corey and frankly the guy is almost annoyingly nice (he went around RubyConf 2012 taking a picture with every damn person there). But Ted Neward saw this turn of events and concluded that Corey’s actions were not orthogonal to his involvement in Software Craftsmanship, but actually influenced by them, and he posted as such on his blog.

Neward’s basic point is that this is the exact kind of behavior we should expect as a side effect of the Software Craftsmanship movement. By it’s nature, it attempts to create a segregation between those who are “in the know” and those who are not, and he felt the behavior of Corey and others was a byproduct of this segregation. They saw Heather as an “other” and were overly harsh in their criticisms, emboldened in so doing by their sense of Craftsmanship. Neward took a lot of shit for this view on Twitter, with most people arguing that this was done by Software Craftsmen, but it wasn’t done because they were Software Craftsmen, and it makes no sense to criticize the entire movement based on the action of a few members, regardless of how high their profile is. Neward responded to all of this feedback in a second blog post, where he reinforces his original point.

Uncle Bob Martin, one of the first five signers of the Software Craftsmanship Manifesto and author of Clean Code and The Clean Coder, then responded to all of this drama with his own post. Bob takes particular issue with Neward’s promotion of what he sees as the opposite of a Software Craftsman, a Software Laborer. In Neward’s words, a Laborer is someone “who cranked out one crappy app after another in (what else?) Visual Basic [...] their apps were sloppy, bloated, and ugly…cut-and-paste cobbled-together duct-tape wonders.” At the end of the post, Neward bows “with respect to the “software laborers” of the world, who churn out quality code without concern for “craftsmanship”, because their lives are more than just their code.”

Bob finds these kinds of developers to be problematic, as his experience suggests that people who make a mess of their code create lots of defects and headaches for themselves and other developers. Finally, Ted Neward responded to Bob as well with one more defense of himself in another blog post which he proclaimed on Twitter as his “last word on the subject.”

It was this last post that inspired me to post my own thoughts. I’m not going to speak much about the drama itself, or the definition of Craftsmanship vs Laborer, follow the links above if you’re interested in that debate.

Something in Neward’s final post struck me.

Know what? I think one thing that got lost somewhere in all this debate is that value is only value if it’s of value to the customer. And in a lot of the “craftsmanship” debates, I don’t hear the customer’s voice being brought up all that much.

You remember all those crappy VB apps that Bob maligned earlier? Was the customer happy? Did anybody stop to ask them? Or was the assumption that, since the code was crappy, the customer implicitly must be unhappy as well? Don’t get me wrong, there’s a lot of crappy code out there that doesn’t make the customer happy. As a matter of fact, I’ll argue that any code that doesn’t make the customer happy is crap, regardless of what language it’s written in or what patterns it uses or how decoupled or injected or new databases it stores data into. Value isn’t value unless it’s value to the person who’s paying for the code.

This, to me, is the heart of the Software Craftsmanship movement. Neward intended this as a critique of Craftsmanship, but I see it as it’s greatest strength.

I see the Agile Manifesto as being customer-focused. It’s values are interacting with people, collaborating with customers, releasing working software, and responding to change quickly. These are things that customers have a good reason to care about. I want every customer of mine to know that I consider myself an agile developer because I think that conveys to them a certain set of principles that they might value.

But Ted’s right, customers don’t care much about if code is crappy, and they don’t care if all of these craftspeople meet regularly after work to “hone their craft”. These are, indeed, not of much concern to customers, at least not directly. The Craftsmanship movement is for me, not about developers focusing on their customers, but about them also focusing on other developers.

I don’t write well-crafted code or go to meetup groups or steadily add value (even if it’s not requested) for the benefit of the customer. I do it for the other developers I work with, and for those who maintain my code when I can’t. It’s this additional layer, the “not-only”s of the Software Craftsmanship manifesto that appeal to me: the adoption of a view that we must not only make our customers happy, but make our fellow developers happy as well.

I’m signatory #214 of the Software Craftsmanship Manifesto, and my self-given title on LinkedIn is “Software Craftsman and Computer Science Geek”. Every so often I see my own LinkedIn profile and this title strikes me as pretentious and annoying, and I consider changing it, but I never do. I always decide it’s more important to leave it and risk looking like a bit of a pompous, self-important jerk. Why do I do this?

I do it because I consider it something of a pirate flag for other developers. It’s important to me that they see this flag, because the label conveys, to my mind, a great deal of meaning to the reader. It’s a shorthand, it lets other developers know an awful lot amount me with two short words, including that I might be a bit of a pompous, self-important jerk. It tells other developers what they can expect of the quality of my work, and what I expect of theirs. It is a label that I adopt solely to aid communication between myself and other developers, not customers.

Sure, I think hiring a team of Craftspeople will be beneficial for customers. I think the codebase will be more easily adaptable to change, I think they’ll get more honest and accurate assessments of when work will be done, and I think they will generally have more positive interactions with their team. But at the end of the day, this team of Craftspeople has chosen their outlook on software development not out of concern only for the customer, but also out of concern for each other.

If Neward wants to sing the praises of his VB-slinging, cut-and-pasting Software Laborer, that’s fine. Such a person may make customers very, very happy, and good for them. But I know that it would make me unhappy if I had to work in or maintain their code, just as I know it would make someone else unhappy were I to be a Software Laborer myself. Frankly, I don’t have much interest in working with Software Laborers as Neward describes them, which is why I fly my Craftsmanship flag high. Does this make me an elitist snob? Yeah, a bit. I’m not trying to be a dick about it, I just know I’d just come home frustrated and drained if I worked for 8 hours a day with a team of people who are just trying to sling enough code to make the customer happy and didn’t care about the codebase itself. The mentality of “the customer is all that matters” is a fine stance to adopt, particularly from the perspective of the customer, but it’s no way to build a team of happy developers.

-Rod Hilton, Software Craftsman Godammit.