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"?
I guess this proves yet again that naming stuff is one of the hardest things we do. I sorta feel like this is a give up, though - replacing 'agile' and 'software craftsmanship' with 'thing'. I'd say all these conversations are already about the thing.
Posted by: Chris Morris | January 15, 2011 at 09:32 AM
"I think we need that sort of thing at the macro scale now." Amen. Just one thing - for the avoidance of confusion - how would you define "macro scale"?
- Bob
Posted by: Flowchainsensei | January 15, 2011 at 09:50 AM
The "Thing of Software Development" needs more attention. There is still so much work to be done to understand it. Yet, I have discovered that I love helping people learn about this "Thing", almost as much as I love the "Thing" itself. That is why craftsmanship resonates with me. One the concrete practices of software craftsmanship is apprenticeship. I haven't yet found any other approach to software development that take such a holistic approach to mastering the "Thing of software development".
Posted by: Redsquirrel | January 16, 2011 at 04:29 AM
I like your "thing" idea. It reminds me of Hamlet... H: "The body is with the King, but the King if not with the body. The King is a thing--" G: "A thing, my lord?" H: "Of nothing..." When I think about great Jazz masters, I am more drawn to their exploration of instincts and the ideas that influenced them than by some guiding principal that any of them lived by. They each had their own way. I once read a Monk quote, "I've never copied anyone, though; just play music.". Some call the "thing" Craftsmanship, and others may give it a different name. But you're right, that the kernel of it is just the thing.
Posted by: Mario Aquino | January 16, 2011 at 06:25 AM
I think the 'thing' is the set of problems and solutions that computers create and resolve, the 'science' of computing and the 'engineering' of the machines and programs that implement that science. Some of this has been captured in books, much of it lies in the muscle memory of its best practitioners.
I do think it is a separate but relating thing to talk about how we, individually and collectively, become better at the 'thing'. I'd agree the 'thing' is paramount, but I think there is a whole separate art/craft/trade/'thing' of conveying and socializing expectations for what makes for professional 'thing'-doers, and it goes beyond the 'thing' itself. To steal Jason Gorman's religion analogy, it's fine to have a set of commandments, but, generally, the practitioners of such things have always depended on communities and buildings and preachers and rabbis and songbooks and... one person showing another the ropes.
Posted by: Patrick Morrison | January 16, 2011 at 05:46 PM
I'm quite convinced that studying the cognitive process and support behind the software craftsmanship is a pretty good bet for a way to go. I suggest reading the chapter 2 of this thesis (http://www2.fas.sfu.ca/ftp/ftp/pub/cs/TH/2002/AWalensteinPhD.pdf) and reflect about it. What you say?
Posted by: Paulo Sérgio | January 19, 2011 at 08:05 PM