Responding to “Craftsmanship, Quality, Dogma, and Pragmatism”
We had the pleasure of hosting Corey Haines during the week of February 23rd when Steve Smith posted some of his thoughts on Software Craftsmanship. I got to talk with Corey about his reaction, which spurred me to read Steve’s post.
I didn’t have as strong of a reaction to Steve’s thoughts as Corey did, but I did comment on Steve’s followup to Corey’s post. A few aspects of Steve’s original post did jump out at me and I wanted to respond to them here.
Steve said:
I’ve heard from several successful business owners that they don’t want to hire artists and craftsmen devoted to making beautiful and elegant code, they want programmers who can get the job done with a minimum of fuss so they can move on to the next task.
The competitor in me gets energized when I hear statements like these. As a successful business owner myself, I am a craftsman devoted to making beautiful and elegant code. Being a craftsman means being devoted to my clients, and my team and I are committed to deploying business value to them on a daily basis. (We deploy multiple times per day.) We work in messy, legacy codebases, and we work in newer codebases where mistakes have been made, and we work in codebases that we are extremely proud of. We constantly strive to increase the quality and business value of our clients’ software. We believe that simple, beautiful, and elegant code increases its business value, and we take incremental steps toward these ideals every day.
When I hear things like “get the job done with a minimum of fuss so they can move on to the next task,” I think of an assembly line worker. That is not the sort of person I’m interested in hiring. I want to develop software developers who make a fuss when they don’t understand the business value of a feature. Our teams have been working on getting better at questioning our clients about their priorities so that we can better understand their businesses, and therefore provide them a higher level of service as we expand these relationships. Teams of assembly line software developers cannot compete over the long-term with teams of self-organizing software craftsmen.
Steve said:
A software craftsman takes pride in his work, but more than that they should take pride in delivering value to the customer.
I could not possibly agree more with this statement. This is the difference between an artist and a craftsman. A craftsman has a customer, and therefore has to balance an entirely different set of variables than the artist, who is creating something beautiful for its own sake.
If the current Software Craftsmanship movement is in danger of anything, it is focusing too much on techniques and practices, and not enough on the foundation of Software Craftsmanship: long-term customer relationships built on successive software deliveries
Steve said:
In many cases, as Bob Martin says, building quality software makes everything go faster, so trading quality for speed makes no sense. However, in my experience this is only true if the team already has all of the necessary skill to do so. If some or all of the team requires training, and worse, if they are resistant to changing their typical modes of writing code, then trying to deliver higher quality is likely to require significant investment in time and energy. The customer should be the one who gets to choose if this is a worthwhile investment for the project at hand.
For teams that don’t have the necessary skill, yet are aware that they could do better, then I would expect to see steady improvement. I would also expect to see the team bring people on board who do have the necessary skill so that the rest of the team can be mentored. And this is definitely expensive. This expense comes from the debt that is accumulated by a bad team’s ignorance, and the sooner you pay off this debt, the better.
For teams that are resistant to changing their typical modes of writing code: I have absolutely no pity for you. I yearn to compete with you for business. This competition will force you to improve or you will be forced to find a different vocation. I want your customers to witness the power of a team that is constantly evolving and improving the way that they work and are open to new ideas and innovations, and get energized when they leverage newly acquired knowledge in order to deliver value to their clients. Teams that are resistant to changing their typical modes of writing code are a millstone around the neck of our industry. We must either inspire these teams to improve or educate their customers about what they should expect from a team of software craftsmen.
