There has been quite some activity in the blogosphere around the term Software Craftmanship lately, and I’d like to chime in with my two cents.
Pete McBreen’s book Software Craftmanship started what now can be called a movement, as is evidenced by the fact that there is a manifesto, a mailing list, and conferences in Europe and the US. One of the best descriptions of the movement, in my opinion anyway, is by Corey Haines.
It all started with a post by Dan North that was critical of the movement. Members risked being elitist, indulging in navel-gazing, and coding for code’s sake. Others, like Liz Keogh, chimed in.
Replies were inevitable, of course, and came from Jason Gorman, Dave Hoover, Ade Oshineye, and George Dinwiddie, among others.
Dan North just replied to the replies, so I guess the discussion will continue for a while.
So where do I stand?
I signed the manifesto because of two main reasons:
- I take pride in my work
- I want to be the best I can be in what I do
And that’s what I think the manifesto and the movement is all about. Let me explain.
Stages of Learning
The craft model assumes that there are different levels (apprentice, journeyman, master) at which software developers operate. That does not mean that software craftsmen want to return to the Dark Ages of the guilds. It simply means that they acknowledge that there are stages to learning. Whether we name those stages after the five stages in the Dreyfus model, the four stages of competence, Shu-Ha-Ri, or something else, doesn’t really matter.
Nor does it matter where exactly we draw the line between those stages. The basic thing to understand here, is that we have to go through different phases on our journey to become ever better. I think that being aware of how we learn, and how learning progresses, helps us learning.
Another thing the craft model emphasizes, is that there are different schools of thought on what is best. There is no one true way of doing things that we can learn. Instead, we must seek out different experiences in different places if we want to become the best we can be.
Don’t get me wrong: the journeyman model, however fascinating, is hardly practical for most people. But you don’t have to literally travel the world to benefit from it. Just keep the model in mind when selecting your next employer, or the next step in your career at the same employer. Take into account what you want to learn, what you haven’t yet been exposed to.
For instance, I learned the basics about databases in college. My knowledge expanded greatly (particularly about the Oracle RDBMS) while working with Kees Verruijt at Redwood. And then that understanding deepened again when I learned about XML databases at X-Hive (acquired by EMC, where I still work).
So, does the manifesto help at all with learning or with learning how to learn? I’m afraid not. That’s why some have suggested adding a Further Reading section to it. But that won’t cut it, since learning is about much more than reading.
You also need to practice and reflect to grow. That’s why there is so much talk about coding dojos, katas, code retreats, or even etudes and object calisthenics.
I can understand that some people get uneasy by all that weird terminology. But I encourage them to look beyond the words. The point is simply that in order to become an expert, you need to practice, as the craft model teaches us.
Beyond the Manifesto
In summary, my position is that there is value in thinking about software development as a craft. That doesn’t mean that I think that the Manifesto is perfect. In fact, it doesn’t help me much in learning or in learning about learning. So where do we go from here? We need more concrete help on our journey to mastery.
But I don’t particularly like the idea of re-introducing guilds through some formal institution like a Software Craftsmanship Council. I also don’t think we need it.
We already have ways of knowing how good people are. We have to, or else how could we hire good software developers? So I think we should start by looking at the types of things we look for in candidates during our hiring process. Something like a Software Competency Matrix would be a good start for an aspiring craftsman to get a feel for what areas to improve.
Score yourself on each of the items in the matrix. Find your weak spots, and improve them through practice, practice, and some more practice. And have fun doing it!
One thought on “Software Craftmanship”