On Software Craftsmanship

@theNorm and I were talking over lunch about Uncle Bob’s post about what software craftsmanship is about and what it means to the participants, the outsiders and most importantly for me, the customer.

Perhaps I was not paying attention, perhaps I totally missed it, but I had not seen anyone link the whole practice back to the customer and why it is enormously valuable for them as well. I’ve been following Corey Haines for a long time. I know he’s a relentless improver. Is that what craftsmanship is? I’ve argued with Matt Otto about it more than a few times. I always felt like I was missing something. As soon as I had read Bob Martin’s post, craftsmanship clicked for me. I think I get it now.

Art and utility come up quite often around the subject of craftsmanship. There are a lot of good arguments on either side for why software is art and why it is not, why it should be and why it should not.

However, we are focusing a bit too much on the ends, are we not? The focus here should not be the code created, perhaps the art is in choosing which approach to take, why that is so and to be able to defend that position from your teammates and the business.

There are many different ways to parse XML. Knowing your options and how to apply them is the true art here. The slew of options that you might apply is what practicing your craft gives you. If speed is your ultimate goal, then you construct your solution with that constraint in the forefront. You go about creating art in that medium.

What you ultimately produce is utility. The business needs it to be as efficient as possible, have we created that? The code needs to be a line of business application, so it needs to run smoothly and maintainable. Have we done that?

Art is the means to create utility. The master creates based on practice, knowledge and love of his craft. Those three things are the art.

Excuse me now, I need to get back to practicing my art.

Codemash Ruby Koans - KOANS!