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.
Teaching is reflection in motion – Ralf Westphal
Did you have an “aha” moment when it came to Clean Code?
Ralf: Yes. When I discovered what I call topological dependencies . That´s when some code does not only depend on some functionality, e.g. function f(), but also on where this functionality is located, e.g. on some service interface. This happens all the time and is not addressed by Inversion of Control or the Interface Segregation Principle.
The point is, even though the Single Responsibility Principle seems to have been observed, so both client and service have only a single reason to change – this is not true. From a business domain point of view it might be true. But there is a second reason for change for the client code. It needs to change if f() is moved from one service interface to another. Not only does it depend on f(), but also on where f() is defined.
Once I realized this, a light bulb went off in my head. Because then I understood one more reason code is hard to change.
Stefan: We had many of them while collecting the principles and practices. There were some moments when we recognized that all the parts fit nicely together. For example recognizing that the principles and practices need to support a value, for example correctness or evolvability, was such an “aha” moment. If a principle does not support one of our four values it’s of no use.
The four values of the Clean Code Developer initiative (www.clean-code-developer.de) are Correctness, Evolvability, Production Efficiency, and Continuous Improvement. Every developer should strive to support them.
How important is it to use tools to automate processes like refactoring?
Tools are important. But we´d like to say in the manifesto style: Thinking over Tools. So we´re focused on thinking, on methods, models, concepts, paradigms at the Clean Code Developer School.
But sure, we use tools all the time. Have to. In the end, we have to produce working software. That means it needs to live up to functional as well as non-functional requirements. And if that´s not the case… we might need to employ tools.
A refactoring tool might be needed to clean up code, to make it more evolvable and more testable.
A profiler might be needed to spot performance bottlenecks.
A mock-up framework might be needed to make testing easier or faster.
If you want to become a ‘master software developer’, you need a tool belt like a master carpenter or any other master of a trade. We’re very clear that it’s the developer, not the tool, that makes good software.
What advice do you have for developers who want to improve their craft?
Ralf: Get yourself a copy of Clean Code . Then find a group of like-minded developers to discuss your efforts in improving your capabilities. And to help you in difficult times – because they´ll surely come. Learning can become frustrating and sometimes boring. It´s good to have someone pulling you through the “valleys of tears.”
See to it that learning is not a one-time effort, but becomes part of your life, your lifestyle. That´s hard, if you´re not used to it. We know that. That´s why we founded the Clean Code Developer School.
Stefan: Practice, practice, practice! You should work on exercises on a regular basis. Don’t just always work on production code but on exercises so that you can make many mistakes. Without having the freedom to make mistakes there is no real learning.
Which topics generate the most interest from students?
Ralf: The more technology is involved the more motivated the students. Learning how to use a mockup framework is easier for them than learning a method like TDD.
But fortunately we´re seeing a change here. People are slowly becoming more interested in concepts and methods. They begin to realize that they provide a good lever. Learning to use a refactoring tool is good – but learning to design and code in a way to need less refactoring in the first place is even better.
Stefan: The most discussions arise when we talk about how to comment your code, how robust your code should be and how to handle null values. We have straightforward opinions about that. But all in all, the students are interested most in how to design a solution before implementing it.
What have you learned from your students?
Ralf: Ok, let me tell you a secret: The main purpose of our trainings is… that we ourselves learn. We constantly learn from our students. Or to be more precise, by talking to them, by showing them something we stumble across bumps in our own thinking. That´s when we learn. We would not have found those dents in our “theory” without teaching. Teaching is reflection in motion, so to speak.
There is a saying in German: “How should I know what I´m thinking before I speak?” So we use training as a means to advance our own thinking. All the time. The same is true for writing articles for journals or blog posts. The same is true for doing talks at conferences. The same is true even for this interview. Each time our thinking becomes a bit more clear.
To learn more about the Clean Code Developer School visit: http://ccd-school.de/