CCD Reflection 1: Red Grade finished

Today is day number 21 of wearing the CCD Red Grade wrist band and time to reflect on the last three weeks.

What have I done in the last three weeks?

• Several code katas
• A little pairing with one of our developers to find weird UI problems
• Initiated the first Coding Dojo in our team - we are going to do weekly Dojos now

How do I rate my performance on the principles and practices of the CCD Red Grade?

• DRY - everything was done only once, I give a high rating
• KISS - almost everything was kept simple or--even better--was made simpler
• Beware of Optimization - I can't remember any optimization but want to rate "not perfect" as I think that some shortcuts were made during TDD (two or more baby steps at once). And taking shortcuts is some kind of optimization as well.
• FCoI - my kata and dojo code was too simple, FCoI could not have been applied
• Boy Scout Rule - interesting experience: during a debugging session we walked through code and saw dirty places BUT at that time we were hunting a very specific system behaviour and did not want to interrupt this task by doing boy scout cleaning. Unfortunately we forgot to clean the code afterwards. Learned for next time: take a note of the dirty location and come back later to clean it.
• Root Cause Analysis - did not happen at all in the last three weeks
• Version Control - 50% done but not for some spiking code experiments and all my private katas
• Simple Refactoring - completely done as integral part of doing TDD
• Daily Reflection - thought about it but not very structured

I gave every of these principles and practices a value from 1 point (not done at all) to 5 points (perfectly done), see image.

Red Grade done, finished, or on-going?

The idea of the CCD initiative is to stay with your current grade until you are able to high perform on all aspects of this grade for at least 21 days in a row. My initial plan was to switch to the next Orange Grade after three weeks regardless of my red performance. I wanted to go on and focus on the next principles and practices - and simply keep in mind that I have to improve my red skills. Now I realize that CCD doesn't work this way. I want to prove significant success in the current grade to myself as a trigger to switch to the next grade. It would be meaningless to go on as long as I fail to apply the boy-scout-rule, root-cause-analysis, and daily reflexions on a regular basis.

I try to do daily reflexions from now on to get self-feedback early and improve my grade performance. To be continued...

CCD: The Personal Experiment

Two years ago I left the path of writing code as I had to deal with leadership, management, and organizational things for my teams more and more. That really was no big deal in the beginning but after a while I felt two important reasons to get back into coding again: (1) something was missing regarding my passion for software development: actual coding working software, and (2) I was not able to participate actively in discussions about all those fancy new things: frameworks, languages, and technologies I've never used.

From my theoretical point of view I knew that Uncle Bob's Clean Code was the right approach to go. This was what I wanted to head for not only personally. I also wanted to work with developers who understand and foster their own software craftsmanship in that way: writing clean and SOLID code, following XP practices, and valuing Agile principles.

In November 2009 I started to contribute to the Agile Skills Project for quite a while but unfortunately this project was running into a dead end in the last months. I still hope it will continue somehow but this is another story for another blog post.

At about the same time in November 2009 I attended a session of Stefan Lieser talking about the Clean Code Developer (CCD) initiative at XP-Days 2009, Germany. For in-depth information take a look at

clean-code-developer.de

but note that there is only a German version available.

CCD was exactly what I needed. It it based on four values which always should be focused by developers:

• Evolvability - take care that software is able to be changed easily and at a reasonable low price late in a project or even after years of production.
• Correctness - software is correct if and only if all functional and non-functional requirements are implemented
• Efficiency of Production - short development time, automated tasks, and low bug ratio are necessary to be efficient
• Reflection - learn and improve often and early (on all the individual, the team, and the organizational levels)

These are good values to follow but they are quite too abstract to know how to do it. Ralf Westphal and Stefan Lieser,  founders of the CCD initiative, did a great job with structuring lots of principles and practices and giving easy-to-start guidance to developers.

The whole system is divided into seven colored grades of which five contain specific principles and practices. A CCD developer starts with the first (red) of these five grades and works with the given principles and practices until she has reached a proficient level in this grade for at least three weeks in a row. Then the developer turns to the next grade and continues cycling through all the grades. This grade system provides an easy way to start with specific things and increases a developer's focus.

So I started with the red grade a while ago and will post my experiences on a regular basis here on my blog.