Almost four months ago we started our initiative “Clean Code Developer @Viaboxx” which is closely aligned to an undertaking originally launched by the team around Stefan Lieser already several years ago [1]. The principles and (best) practices of CCD in turn are largely based upon the book “Clean Code” by Martin Fowler, which for me belongs to one of the fundamental lectures for every serious software developer.
The idea was to improve code quality at Viaboxx. Good quality leads to satisfied customers and enables us to react to changed requirements without the risk to lose stability or maintainability of our products.
One essential thing I learned during my years as a developer is that there’s no maintenance phase. Exceptions do exist: I once worked for a company that did not pay enough attention to code quality – leading to an enormous effort (i.e. Big money!) to eliminate sporadic bugs and unstable behavior without being able to deliver new features over a long time.
The solution: Empower every single developer to write good code and encourage them to improve bad code “on the fly”! Here comes the clean code initiative into play: it delivers lots of best practices and explains principles that lead to better code, all grouped into 5 colored grades. The concept is simple and reflects adult learning: “small appetizers, constant repetition”. Each grade lasts 3 weeks during which we focus on the principles and practices assigned to that grade when writing software. In the end, you start all over again!
Because we are unable to understand everything at once, I further divided each grade into parts. Before Corona came up, I hang out a new part of the current grade each week at a prominent place in our office. The goal was to achieve a high awareness of code quality by being present visually for everyone, every day. Now I post a message at the beginning of each week as a reminder, linking to the current part of the grade in our wiki.
We now already “lived” one complete cycle (red > orange > yellow > green > blue) and started last week with the red grade for the second time. Each developer can decide what to extract from each grade depending on the personal current state of knowledge. However, the person should “dig deeper” into each cycle. Speaking of myself, I experience a higher awareness of code quality as well as “smelling” bad code – and mostly knowing how to improve it!
The CCD also leads to rising discussions to a higher, more abstract level. Taking reviews as an example, it might be sufficient to say: “Well, that’s YAGNI” and, for the author, it should be clear what that means for his code. For me, personally, I would say I write quite good code by now – until the next code review proves me wrong. 🙂 But, hey, it’s all about learning and communication, isn’t it? 😉