The importance of craftsmanship

Crafts such as carpentry and masonry - just to name two - exist since many thousands of years. We call them traditional crafts and most practitioners of these crafts keep up the traditions for a good reason.

For example German carpenters adhere to very strict rules that govern training of new craftsman. Not only that. Many of them are proud craftsman and prefer to work in traditional clothing. One item of that traditional workwear is called Ehrbarkeit which translates to respectability. It is similar to a tie but instead of going around the neck is just a narrow strip of fabric. Depending on the guild the carpenter belongs to the color of the Ehrbarkeit varies.

The basic idea behind this symbol is to tell a potential customer that the carpenter is a respected and responsible craftsman who performs work that is governed by the standards (quality standards that is!) set by his guild. He is a respected craftsman because he earned that respect through achievements and has passed exams to be accepted as a member of the guild. It is expected that he will protect his reputation by not delivering bad quality or bad value.

In software development we don’t have a history of a few thousand years to draw from. The computer was invented almost “yesterday” when in Konrad Zuse built the Z1 between 1935 and 1938. The first high-level programming language Plankalkül was created by Konrad Zuse between 1943 and 1945. So our craft is extremely young and in its very short history many attempts have been made to either associate it with math or engineering or simply determine it were a field within these disciplines.

Only in the last 10 years people have started to think about software development as a craft and the software craftsmanship movement appeared.

My understanding of being a software craftsman is that I have to be honest, open and truthful. I need to deliver value to my customer and make decisions based on my experience. I need to know how to use the tools of my craft effectively and with efficiency. And I need to protect my reputation by not engaging in practices of which I know that they are not effective or harmful to the health of the project or may lead to problems for my customer in the near future.

Here is an example. If my customer expects me not to practice Test-Driven Development in order to get results faster and my long-term experience is that by doing TDD I can create code of higher quality that is more maintainable and more reliable than code without tests, then I should never accept any direction not to do TDD. If I did, I certainly were about to loose my reputation or were committing some sort of treason to myself.

As a craftsman I should know why I do things in a certain way. I should be able to explain and justify my decisions and, of course, deliver good results to the benefit of my customer.

The more software craftsmen work in all the companies that develop software, the more the craft improves. The more craftsmen are out there, the better customers learn what high quality software looks like and what it takes to create it. As a consequence the easier it will be for good craftsmen to find customers and the harder it will be for all the charlatans who do a lot of damage to our customers.

This article has been posted to social media sites. There might be comments. Just follow the links: