Today I crossed the path of a blog post on Why should we care about software craftsmanship. It’s basically a two part blog entry from Gael Fraiteur who visited the Software Craftsmanship conference in London, and reflected afterwards back on what Software Craftsmanship is to him, and where he sees problems with the notion of the term heavily influenced by a talk from David Harvey called Danger – Software Craftsmen at Work. Uncle Bob Martin wrote an excellent reply to the concerns here, which I won’t repeat. From my perspective there is one important argument missing: on customers, business representatives, and project stakeholders. That said, I agree to everything from Uncle Bob, but here is what I would add.

The point I counter-argument against is this excerpt from Harvey’s third argument:

Although software developers have their own definition of craftsmanship, what eventually matters is the perception of our customers. By choosing inappropriate metaphors, we are increasing the gap between those who build software, and those who use it.

The fourth value statement in the manifesto that we came up with is

Not only customer collaboration, but also productive partnerships.

This means that we strive not only to work closely with the stakeholders and future users of our software, but we build up a reputation of our work towards our customer. They know what we are able to deliver them. All this is settled in the notion of productive partnerships. We can build up our reputation based upon our work, and we can point to successful projects from our professional past.

While we developed the Ethics of Software Craftsmanship, we had this aspect fully in our heart. Take the first statement entitled “We care”:

We consider it our responsibility 
  to gain the trust of the businesses we serve;
    therefore, we
      take our customer's problems as seriously as they do and
      stake our reputation on the quality of the work we produce.

I already mentioned the reputation aspect from this sentence. Beyond this we also take the problems of our customers as seriously as they are taking them. We aim to build trust of businesses because we understand that this is our responsibility. We care about that.

A second thing I will slightly throw in is the phrase that Craftsmanship is opposed to Software Engineering. This is not the case. A while back I wrote an article on this, that I called Developing Software Development. In it I explain that these kind of metaphors leave out necessary details as any model does. Instead we should maybe try to use those aspects from these models that help us in the current situation. For Software Engineering this is the notion of trade-off decisions, as Jerry Weinberg made me aware of in his fourth volume on Quality Software Management. But since Software Engineering lacks the mention of a model to explain how to teach people new to our craft what to learn, McBreen claims the necessity of Software Craftsmanship.

But let’s not stop here. I think there is lots more to discover about successful software development in the years to come.