Like many developers, I have a shelf of books that influenced me most. One of these is Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin, affectionately known in the community as “Uncle Bob”.

Software development is a craft, and like any craftsmen, we strive to make quality goods. Clean Code presents the principles, patterns, and practices necessary for creating quality software. It then provides case studies and demonstrates how the techniques are used to turn working software into quality software.

It takes time and experience to become excellent at a craft, and let’s face it, this isn’t something taught in school. That is, until recently, when I discovered the Clean Code Developer School (CCDS). I had the chance to speak with Ralf Westphal and Stefan Lieser, the founders of this unique initiative. They shared with me their reason for founding the CCDS, common Clean Code mistakes, how to become a better programmer and getting through the “valley of tears”.

How should I know what I'm thinking before I speak?

- German Proverb

What are the most common Clean Code mistakes that you see developers make?

Ralf: I´d say doing stuff of dubious value is the number one problem. You Ain't Gonna Need It (YAGNI) is the number one principle violated. Closely followed Premature Optimization , which is a special case of YAGNI .

Stefan: On the other hand I think, the biggest mistakes are dependencies. The more dependencies you have between functional units of your code, the bigger the problems for fixing and changing the code. Even automated tests are a lot more difficult because of the dependencies. So get rid of them.

How did the Clean Code Developer School come about?

Ralf: The Clean Code Developer School was born out of dissatisfaction with current training formats. After completing a recent in house training on Clean Code development, we asked the participants, how they intended to transfer theory into their everyday developer routine. The answer was “We don´t have a plan. We probably won´t even use the stuff within the next 4-6 months.” To us that meant that the whole training had been a waste of time and money – at least for them. Because there´s no way you can retain freshly learned principles and practices without further exercising them for such a long time.

Did Bob Martin’s book, Clean Code, influence the curricula?

Ralf: Yes. Stefan and I had read the book around the same time in 2008 and like it very much. We met at an open space conference and started discussing it. And not long after we were asking ourselves how to carry its message to a broader developer community.

From that the Clean Code Developer initiative (CCD) was born. We took Uncle Bob´s book as a starting point and compiled 42 principles and practices we deemed to make up Clean Code development from different sources. They are documented in a wiki – but we did not stop there.

Our feeling was, the biggest hurdle for Clean Code adoption was not motivation or lack of knowledge of these principles and practices. Rather it was a lack of a plan. So we went to great length to structure those Clean Code building blocks. In the end we came up with 5 so called “grades”, each containing a couple of principles and practices. They are ordered in a manner as to make learning easier. First come building blocks you can start using right away without asking anybody. Last come building blocks relevant for whole teams.

The grades each have a color assigned – from red to blue – and developers can buy small wrist bands to show off on which grade they are working. This idea partly came from Uncle Bobs green wrist bands, and partly from other sources.

Contrary to what some believe, the “grades” are not to meant to express any level of knowledge attained. They are just chunks of principles and practices ordered in a manner to make progression/learning easier.

Lastly we put a set of values on top of the principles and practices. Because why should anybody learn any principle or practice at all? The purpose has to be very clear. That helps motivation. That helps judging the importance of the Clean Code building blocks.

Those values are: correctness, evolvability, production efficiency, and continuous improvement. All principles and practices have to make clear, which value(s) they help to support. Customers are not interested in a developer applying a certain principle. But they care about whether the resulting code is correct or can easily be changed in the future.

Today some 3,800 developers are members of the CCD discussion forums.

Stefan: The book gave us the initial idea to collect the 42 principles and practices of the Clean Code Developer initiative. But Martin’s book contains only a fraction of the things we collected at http://clean-code-developer.de.

Can you tell us about a time when you violated the Clean Code principles? And what happened?

Stefan: I must say that, many years ago, I wrote SQL statements into VB6 forms. Yes, been there – done that. The result was that adding features or even fixing bugs was a nightmare. I learned the hard way that writing dirty code isn’t a great idea.

Ralf: For some 25 years of my programming career, I violated most all of the Clean Code principles. I´d rather not talk about that in detail.

But here´s a recent example of smaller scale: Stefan and I were working on a file synchronization tool. We did it according to the book: small code units according to the Single Responsibility Principle , component orientation, unit tests, continuous integration, walking skeleton etc.

Except we did not have any acceptance tests, we were so carried away by all sorts of cool ideas that we simply forgot to start with them. And that really killed our production efficiency in the end. No, we´re not proud of that part of the project.