Mastering the practice

Overcoming the limitations of Software Craftsmanship

UweFriedrichsen
japan_kata

Originally appearing in November’s JAX Magazine, Uwe Friedrichsen acts as our sensei in explaining how to overcome 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

Author
UweFriedrichsen
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
Comments
comments powered by Disqus