It's been an interesting week in the software craftsmanship blog space. Dan North wrote one up that expressed the issues that he had with the notion of craftsmanship, and Jason Gorman just wrote one calling for an end to holy wars in the development community. I look at those opinions, and I can't say that I disagree with them. In fact, I think I'd carry it a bit further.
Every once in a while, when I'm talking to someone they identify me as part of the Software Craftsmanship movement. I guess I am, but I don't go out of my way to present myself that way. The same is true with 'Agile.' I hardly ever use the word anymore. It's just a label for a set of values and practices. When Jason talks about 'Holy Wars', I see something far more innocuous. What is see is sets of people looking for banners to rally behind. It's a very human thing. People form movements, they identify with them, they persuade others to their cause, and, frankly, a lot of good can come from it if the goals are good and people walk the walk that they talk. But, at the end of the day, it's all philosophy. It's all of us huddling beside a campfire and trying to figure out the right way to be in our work. It's more than that, actually. It's inward facing. A collective form of self-preoccupation.
As much as I love working with people and aligning values and practices, I love the "thing." The "thing" I am talking about is the set of extremely concrete challenges that we confront as software developers in code and in teams, and the way that we confront them. Last week, I visited some people from Obtiva and we started to identify a set of ways that Rails applications commonly go wrong. It's the thing that many people don't want to look at. They know that code gets harder to deal with over time, and they know that refactoring is the path out, but how many of us are actively looking at why? Or, developing roadmaps to confront these technical challenges. There are two forces at work here, there's the Larry Wall-ish "the best programmers are lazy programmers." They find the easier way. But, there's also the fact that as much as we try to dodge, sidestep, or creatively finesse away problems, many are still there. These problems are part of the "thing" and we have to talk about the "thing." We have to talk about it a bit more than we need to talk about "us", in my opinion.
I guess I can explain what I am after by referring to something Kent Beck did years ago. When he wrote the book 'Smalltalk Best Practice Patterns', he set himself the goal of not doing anything in his code until he understood why he did it. The set of patterns in the book resulted from that reflective exercise. It's very deliberate practice. I think we need that sort of thing at the macro scale now. We need to know why we do things. The things that work and the things that don't. We have to explore the sinew and shape of software as it grows and learn how it's impacted by us. Learn the ramifications of our early design choices -- how to make broad changes in code and when to throw it away and start over. And, yes, we can call ourselves craftsmen, or engineers, or whatever. And, we can have great values, but we have to concentrate on the "thing."
Don't take this wrong. I know that many people do this. It happens in parallel with talk about craftsmanship, etc. We are advancing the state of practice. But, what would it be like if the "thing" were the top topic of conversation? If blogs, discussions, and conference sessions were all about the "thing"?