Mastering the practice

Overcoming the limitations of Software Craftsmanship

Originally appearing in November's JAX Magazine, Uwe Friedrichsen acts as our sensei in explaining how to overcome the limitations of '''Software Craftsmanship".

Software Craftsmanship is a movement that gained a lot of momentum and attention in recent years. Its claim is that if you stick to its values, you will become a better software developer. Yet, the usual interpretation of the term has limitations. This article will take a closer look at the limitations and how to overcome them.

The Manifesto for Software Craftsmanship

The term Software Craftsmanship gained a lot of attention in the recent years. The origin of this movement can be found in the Manifesto for Software Craftsmanship. This manifesto was designed and written down by people who became convinced that the agile values and principles in themselves are not sufficient. They were convinced that it is not sufficient for good software development to be just agile, but that you – casually speaking – also have to be proficient in your trade.

Accordingly the manifesto is expressed as a continuation of the Manifesto for Agile Software Development. As the agile manifesto it uses a left-side-right-side presentation. The form used is:

“Not only <value of agile manifesto>, but also <extended value of craftsmanship manifesto>”

This way it was possible to pick up and refine the four values of the agile manifesto. The four values the craftsmanship manifesto calls for are:

  • well-crafted software
  • steadily adding value
  • community of professionals
  • productive partnerships

It may look like a simple refinement of the agile manifesto (and indeed it came into existence this way), but actually it is much more than that. Even if the manifesto was designed as a result of dissatisfaction with the way the agile values were implemented in practice, Software Craftsmanship goes far beyond Agile and therefore appeals to many people who don’t find Agile appealing.

The Usual Interpretation...

For me, the manifesto and the values associated with it are very valuable and very important because in my opinion they push the right ideas – values we badly need to be successful in an IT world where complexity and pressure to deliver always rise.

Great, so that’s it! We are done, aren’t we? Let’s just stick to the values of the manifesto and we are set for our upcoming IT life. So, let’s go to a local craftsmanship community nearby and learn from them. What are the typical things you will learn there?

Learn lifelong. Yes, this is important for sure, especially in a domain moving as fast as the IT domain. But actually, that is not new wisdom. All of us have heard that before but admittedly we cannot be reminded of it often enough. Fine, what else? Maybe something more concrete.

Do Coding Katas or Code Retreats or Code Camps. Do TDD (Test-Driven Development) and Clean Code. And things alike. Ah, okay? And what are those things good for? They help you to become a better software developer according to the values of the manifesto. Okay, that looks like fun. Let’s get started with it. Let’s do some katas, let’s learn about Test First, Baby Steps and so on.

Note: If you do not know what those terms mean, I definitely recommend to browse the web or to join a local craftsmanship community nearby in order to learn about those things. It is your personal decision if you want to stick to the concepts those terms represent but as a good software developer at least you should know what those terms (and some more) mean.

So you get started and it feels good. And you get new insights about writing good code. Then, why am I talking about limitations in the abstract in the article?

...and its limitations

Figure 1: Limitations of the usual interpretation of Software Craftsmanship

Before I start to discuss the limitations of the usual interpretation, I would like to emphasize that in my opinion there is nothing wrong with the topics mentioned. On the contrary, there is a lot of value associated with coding katas, code retreats, TDD and all that. You should definitely become familiar with those concepts if you are not yet.

But if the whole discussion only revolves around enhancing coding skills, then there is something wrong. Why? The answer is twofold (see Figure 1). Let me start with the first dimension.

The eternal apprentice

Coding Katas and Code Retreats are usually smaller exercises to train a certain basic coding skill. This kind of exercise definitely makes sense for a junior software developer, but if I am still stuck with coding katas after 5 or 10 years of software development experience, I probably did not grow much as a software developer.

In martial arts, where the term Kata comes from, katas are strict series of movements that students use to train specific movement patterns. Depending on the martial arts style there are more or less katas, comprising of different levels of difficulty, but all of the styles have in common that masters do not improve by katas anymore.

A martial arts master must be able to select his or her movements according to the given situation, to any arbitrary attack pattern without following a strict series of predefined movements. You cannot learn that by only doing katas all the time. Katas for sure help to do moves right but they do not help to do the right (appropriate) moves to counter an arbitrary attack pattern. A master who only can reproduce predefined movement patterns is not a master but still a student, no matter how perfectly he or she executes the moves. And in most martial arts styles masters do not use katas to improve their skills but they have found different ways for themselves how to do it.

Again, there is nothing wrong with coding katas and code retreats, but if that is all we do to improve, then – using the analogy from trading – we will stay apprentices forever. We do not become a journeyman – not to mention a craftsman master at all.

Violating the values

If that were the only limitation we could just shrug and say, that limiting oneself this way is not very worthwhile but also not serious, even not unusual: Staying behind one’s own potential is waste for sure but we see this all over the place. So what? Bad luck, we could say, if there were not the second dimension: The limitation described before violates the values of the manifesto and this is serious for sure.

The usual interpretation only addresses the first value of the manifesto (well-crafted software). The other three values are not addressed at all.

  • The second value (“steadily adding value”) is completely left out because value is defined by the customer, not the developer. If we only focus on coding-related topics we cannot know if we add value or not. We do not learn anything about customer value by doing coding katas.
  • Also the other two values (“community of professionals” and “productive partnerships”) are not addressed: You will get the latter only if you can talk at eye level with your stakeholders, which you do not learn by doing coding katas.
  • And you will be perceived as “professional” only, if you are capable of understanding their needs and pains and adding your share to the solution. This also requires a lot more than just improving coding skills.

Without denying the need for better coding skills, focusing only on improving those skills violates three out of four values of the manifesto. Sometimes I get the feeling that the term “Software Craftsmanship” is misused by some people as a convenient legitimation to focus on the activities they like most (writing code) and to put aside the activities they do not like so much (all the other activities belonging to professional software development).

Also I am afraid, if we as a community do not manage to balance all four values reasonably, Software Craftsmanship might get the reputation of a lame excuse for people who do not care about anything but hacking code. Probably I am a bit too pessimistic about this but focussing on coding skills only definitely is not enough.

Doing it better

Summing up, the usual interpretation as described above has two limitations:

It limits individual development. The apprentice level is not left. A development to a journeyman or master level does not take place.

The values of the manifesto are violated. Only the first value is considered, the other three values are neglected.

This raises the question: How do we do it better?

Figure 2: The path to becoming a real Software Craftsman

I think there is a place for the narrow interpretation, but it needs to be embedded into a broader context. Improving coding skills is a valuable starting point in the journey towards a software craftsman. But as personal experience grows, it becomes necessary to build up expertise beyond the pure developer perspective to become a real craftsman.

Or at greater length, craftsmanship means steadily improving the individual competencies with the purpose to create added value and quality for our customers. Our improvement activities are not guided by our personal preferences but by this purpose.

Being a junior developer this means, I have to start building up expertise in a well-defined area first because I cannot learn everything at once. Since working code is a core result of our activities it makes sense to start with improving my personal coding skills.

But with more experience I need to broaden my expertise, because coding is just one out of a series of skills I need to create added value and quality for my customers.

For instance, a good craftsman needs to respond to his customers. Therefore he needs to learn their language to be able to communicate productively with them (and to become accepted by them).

He needs to understand the needs and pains of his customers and he also needs to carve out those requirements a customer is not capable to couch in words easily.

He needs to balance competing forces and to identify good compromises. He needs to make transparent the trade-offs of the alternative solution approaches and to support the customer to find the solution that matches the customer’s priorities best.

He needs to understand the environment the product is embedded in and to deal with the constraints and conflicts which may arise from it.

And so on – again, this needs a lot more than just excellent coding skills.

Conclusion

After all, you can compare a software craftsman to a trade craftsman. A trade craftsman master does a lot more than just standing in his workshop all day crafting products. He takes care about dates and money, resolves problems, coordinates suppliers and customers and does a lot more.

Likewise, a software craftsmanship master needs to take care about a lot more than just making sure the product he creates meets his personal quality standards – and he needs to acquire the competencies required for that.

This is not possible if we reduce Software Craftsmanship to Coding Katas, Code Retreats and other code-only-related topics. This might suffice at the start of our craftsmanship career. But as we grow we need to leave the comfy developer chair and go on a journey as a trade journeyman does: We need to learn about other departments and domains, we need to learn about the needs and specialities of our customers and partners and we need to improve our soft skills..

Of course it is important not to forget our coding skills on that journey and we might want to do some coding kata or code retreat on our way. But as true software craftsmen we know a lot more than just how to write nice code.

Author Bio - Uwe Friedrichsen has a long track record as architect, developer and project manager. His focus areas are architecture, agile software development and scalable systems. Besides writing articles and sharing his ideas on conferences he is also one of the founders of a local software craftsmanship community in Düsseldorf, Germany.

Image courtesy of stormwarning

Uwe Friedrichsen
Uwe Friedrichsen

What do you think?

JAX Magazine - 2014 - 03 Exclucively for iPad users JAX Magazine on Android

Comments

Latest opinions