Where is the Controversy in Software Craftsmanship?

I recently gave a talk about Professionalism and Craftsmanship in the Software Industry to a group of my work colleagues. I thought I was well prepared, I had been very careful to read around the areas that I felt were controversial and would raise an eyebrow or two. It turned out the parts of the talk that were taken as controversial were not the parts I had anticipated.

I started the presentation with the question "Why is Professionalism Important", and I related the story of the Computer-Aided-Dispatch system introduced by the London Ambulance Service in 1992. The computer system was a disaster the media estimated that 20-30 people died as a result of the failure. There were a catalogue of mistakes and plenty of missed opportunities that could have averted the disaster that ensued. I used this example as a sledge hammer to drive home the importance of Professionalism, selecting a number of the problems that were arguably due to a lack of Professionalism in the software industry. I noticed a few sceptical faces when driving home this point, but there were no comments on this until the end of the presentation.

It turned out that a small number of the audience felt it was inappropriate to compare a Safety Critical System with the financial systems we work with. I found this somewhat astonishing, and pointed out that although our systems do not directly deal with people's safety, that does not mean that should our systems fail they could not have devastating effects. For example, were we to inadvertently charge a Debit Card a greater amount than we should, we could potentially empty a card holders account of funds. As an extreme example, the temporary financial loss could easily prevent the card holder from buying life critical medicine. The example was intended to be extreme to push home the importance of Professionalism. Presumably those arguing it was inappropriate feel that Professionalism is less important when working on a non Safety Critical System.

I borrowed the "It seems to me" quote by Uncle Bob to help justify the idea that TDD is a prerequisite for Professionalism. I was surprised the idea that TDD is a prerequisite for Professionalism did not prove to be a hurdle; it turned out the "It seems to me" quote was controversial. The quote looks like this:

  • It seems to me that shipping shit is unprofessional.
  • It seems to me that not knowing whether you are shipping shit or not is also unprofessional.
  • It seems to me that you don't know whether you are shipping shit unless you have tested what you are shipping.
  • And, finally, it seems to me that if you don't have very high test coverage then you have not tested a large part of the code you are shipping, and therefore you don't know if you are shipping shit or not.

The third point was argued against by one member of the audience who stated that sometimes you can't know whether you're shipping shit because you haven't been able to test it. And under those circumstances it's okay to ship. I'm unsure if something was lost in translation, they had agreed with the point that not knowing whether you were shipping shit was unprofessional. But they felt that professional software developers had to do as the business asked, and if that meant they would have to cut some corners to meet a deadline they would be forced to take the pragmatic approach and do so. I was unable to persuade them otherwise.

After watching a video of Corey Haines talking about Practice, I decided to include two slides from his presentation. In his video Corey states that he hates the word "Pragmatic" because it so often used as an excuse for not doing things in a good way. When I first heard Corey Haines say this, it took me a while to come round to his point of view. The reason it took me a while was because I rather like The Pragmatic Programmer, and it immediately felt as though it were taking a shot at its contents. Thinking it through I don't believe Corey intended to criticise the book, he simply dislikes the way in which pragmatism is used as an excuse. When I watched his video I was unable to argue with his example in which he points out there are many good ways to do things, but many more bad ways. What really counts is that there are lots of right solutions, so make sure you pick one of those. If you struggling to reach a deadline, pick the right solution that is going to require the least effort.

I liked Corey's point so much that I chose to include it in my presentation. Although I had been unable to argue against the idea after seeing the example Corey provided, it seems my audience were less receptive to the idea. I suspect some of them were considering the The Pragmatic Programmer, and were perhaps encountering the same thoughts I had initially harboured. Oddly enough, the argument that one of my colleagues made against the "It seems to me" quote, had made use of the word Pragmatic. For me, this reinforced Corey's point of view of the word Pragmatic.

I have heard both Uncle Bob and Corey Haines talk about when you're in a tight spot you should pay extra special attention to your disciplines. The idea being that the disciplines are the cornerstone of what you do, if you forget about them when you're in a tight spot, that spot is going to become even tighter because you're more likely to make mistakes. I interpreted this as "Do the right thing, especially when you have to get it done". It turns out, this too is controversial. A member of my audience argued that if one of our systems were to crash, we had to get it running again as quickly as possible, even if that meant not doing the right thing, because the right thing would be slower. When I questioned them to see if they meant that we should do the wrong thing (the wrong thing being the opposite of the right thing), they vehemently disagreed that that was what they were suggesting.

It seemed that the terminology "right", "wrong", "good", and "bad" were being interpreted differently. I took their example further, by posing the idea if we were to rush to fix the problem, and were to ignore what we knew to be the right approach, we might make matters worse. For example, we might corrupt the various databases. I'm a little hazy as to what happened at this point. There was no come back, but also no acknowledgement that rushing into the situation would be a mistake that could cost the company dearly. I'm still inclined to think that the problem here was down to the terminology "right", "wrong", "good", and "bad". Perhaps in future I should clarify these to a greater extent before using them so liberally.

One aspect of Software Craftsmanship that I struggle with is the Software Craftsmanship Manifesto. I like the manifesto, although I don't believe it helps define what Software Craftsmanship is. My biggest gripe with the Software Craftsmanship Manifesto is that it is overlaid on the Agile Manifesto. I don't believe that Software Craftsmanship is intrinsically linked to Agile; I do not see why you cannot buy into Software Craftsmanship without practising Agile. I purposefully left the Software Craftsmanship Manifesto till the end of the presentation. I explained the Software Craftsmanship Manifesto and also explained why it is that I don't think it should be taken as the core of Software Craftsmanship.

At this stage I mentioned some of the problems that Software Craftsmanship had encountered to date. Perhaps its biggest problem is that it is seen by a number of people within the software industry as an elitist group. I saw some smiles and understanding nods at this stage. These smiles were coming from those who had rejected so many of the ideas to this point. Was this why I was struggling to convey the ideas behind Software Craftsmanship? Was it because of a preconception that Software Craftsmanship was little more than an elitist group? One person offered their input, they felt that Software Craftsmanship was being interpreted as an elitist group, and that the reason for this was because of those who championed it. Funny, it's the people that champion Software Craftsmanship that inspire me.


The difficulty I had in conveying the idea of Software Craftsmanship wasn't because of the more radical parts of Software Craftsmanship. It was because of the controversial aura that Software Craftsmanship has apparently established for itself simply by championing the idea of working professionally. Like convincing doctors to wash their hands? If only I had a pocket Uncle Bob.

Posted in Software Craftsmanship