Posts tagged software craftsmanship

The title of this post was the reply Enrique Riepenhausen gave when I asked him and Joe O’Brien, amongst others, how you sold Software Craftsmanship to your clients. I had been wondering for a while how you explained the advantages of software craftsmanship to a non-technical client. How do you differentiate yourself from the the competition in a manner that a non-developer could appreciate and understand?

As a developer, and one that has seen (and to my shame, participated in) his fair share of corner-cutting, I understand the need for craftsmanship. I really get the need for the principles laid out first of all in the Agile Manifesto and latterly in the Software Craftsmanship Manifesto. I understand how they make for better software and better relationships, not just within teams but also with the clients those teams create value for. However, I just couldn’t see how you explained that to prospective clients, nor could I see how you could translate it into something that they were willing to pay extra for (at least in the short term). As Enrique correctly pointed out though, you don’t sell craftsmanship. At the time I thought, “Great! Excellent! That’s the point I’ve been missing.” However, afterward, the more I thought about it, the more confused I got. If you don’t sell your craftsmanship credentials, how _do_ you differentiate yourself from the competition? This week I had an experience that not only gave me the answer, it showed me that I was asking the wrong question!

This month I changed my car insurance from Insurer A to Insurer B. I’d been happily insured by Insurer A for the last two years and was always impressed with their service. The documentation that accompanied their insurance was well laid out and easy to understand, their staff friendly, well-informed and helpful, and the price (whilst not the cheapest on offer) was very competitive. This year, they put the cost of insurance up quite steeply and so I went to look for another insurer. Insurer B were a *lot* cheaper. In fact, they were cheapest insurer that I had heard of on the comparison site. I decided that I would go with having extra money in my pocket rather than sticking with the insurer I knew, and so I moved.

And so it came to pass that my insurance documents came through from Insurer B. So I got on the phone to Insurer A to let them know that I was canceling. They could not have been more helpful. Within a couple of minutes I had canceled my existing insurance, been forwarded proof of my no claims discount and informed of everything I needed to know as we went along. Insurer B, on the other hand, called me at work, tried to sell me features that I’d already explicitly declined on sign up and then tried to sell me various other products that they happened to have.

Now, the point here (and this is crucial) is _not_ that the cheaper insurer turned out to be the worst. The reason I moved to Insurer A in the first place was because my previous insurer had been more expensive. That previous insurer had also tried it on with the “trying to sell me things I’d already declined” shenanigans. The point here is that, even though I was canceling my insurance with them, Insurer A still went above and beyond to help me. Their focus was on me as a customer, even though they were about to lose my custom. That impressed me to the point where I will be taking my insurance out with them again next year, despite the extra cost.

So far, so very “Thought For The Day”. How does this relate to my software craftsmanship question? First of all, it showed me that I was asking the wrong question. I was approaching software craftsmanship from the point of view of selling it. Making more money because you were crafting a better product. This is, I now believe, the _wrong_ way to look at it. We are craftsmen because we want to build better software, because we want to have good relationships with our customers and because we want to further the state of the art in our chosen profession, not because we want to get paid more. Secondly, Enrique is right. We don’t sell craftsmanship to our clients. They come to us because they have heard that we are great at what we do, or they have seen examples of our previous work. Like my experience with Insurer A, those we do business with will sing our praises because we always put them (or at least their best interests) first and foremost. More than that, they will come to _trust_ us. Once that happens the money will follow, only by that point it will be a bonus over the true reward of craftsmanship. The pride of a job well done.

In the spirit of refactoring to keep things clean, I’ve decided to move the book list from the original post to here. This should hopefully make it easier to use. Please add any new recommendations to this list.

Agile Software Development: Principles, Practices and Patterns (aka PPP)

Apprenticeship Patterns (if you’re thinking of reading Apprenticeship Patterns, Hashrocket are covering it in their Bookclub)

Clean Code

Mastering Regular Expressions

Object Thinking

Smalltalk Best Practice Patterns

Software Craftsmanship

The Art of Unix Programming

The K & R Book

The MIT SICP course (aka The Wizard Book)

The Passionate Programmer

The Pragmatic Programmer

The Refactoring book (original) (Ruby)

Working Effectively with Legacy Code

Any book by W. Richard Stevens but Advanced Programming in the Unix Environment and the Unix Network Programming Volumes in particular.

Finally, some great advice given to read through the man pages on your system. This also applies to reading the code for any application/plugin/gem etc. that you use. You can learn a lot from other people’s code/documentation.