Clean Code Development Part 1: A Question of Personality and Teamwork
Today, on the 256th day of the year, we celebrate the Day of the Programmer, an official day that recognizes the profession. But what rules should a “good programmer” actually follow in order to build high-quality software?
When I, the content manager of an IT company, think about the core activity that developers perform - writing source code - naturally the first thing that comes to mind is clean code development.
10 years after the release of the software developer bible
Ten years after the publication of Robert C. Martin’s standard reference, I used interviews with our developers to evaluate what clean code development (CCD) can do and what hurdles are encountered when integrating this approach into the everyday life in software development.
Do you have to have a particular personality to be interested in clean code?
One thing is clear: Every software developer has a different educational background, prior experiences, and divergent interests. As a result, developers take different approaches and develop different ways of working over the course of their careers. Depending on their personality, some developers prefer to follow the code advice of others and hope that they will be able to get by on that (the Jesse Pinkman type). Others take a pragmatic, do-it-yourself approach à la MacGyver: they work by means of quick bug fixes and eschew the perfectionist demand of always delivering good quality code. However, many developers strive to live up to the ideal image of the “Rain Man,” who – as t3n described in its jocular survey - breathes code and can easily overcomes any of the problems that developers typically encounter in their everyday lives by deploying faultless lines of elegant and effortless code. It is these Rain Men in particular who try hardest to introduce more quality into software development as clean coders. In the end each developer is responsible for making a long-term commitment to clean code principles and practices, so he must be prepared to constantly review his own performance and revise his approach. Therefore, it is invaluable to possess an intrinsic motivation to continuously improve oneself and remain receptive to innovations. Even in 2008 the concept of “agile software craftsmanship” was already so important that Uncle Bob used the term in the subtitle of his book Clean Code. Software craftsmen who work according to a certain quality standard today tend to utilize various architectural approaches (DDD, SOA, microservices…) and methodical procedures (TDD, CD or pair programming …). According to conventional wisdom, there is no way around clean code development when working on specific code production tasks.
Is CCD really worth the effort?
Well, the guys here in the Cloudogu team would tell you: “It sure does!” Our developers told me that at first it took them some time to adjust to the process of rechecking each line of code to ensure that only one level of abstraction was chosen per method, descriptive names were used, instructions and queries were separated, repetitions were avoided, the code was optimally formatted, classes were kept small, etc. Logically, it makes sense to write code that it is understandable and not too complex from the very start. It should be written to allow interchangeability and explain itself through names that convey meaning. But in our project, too, it was initially felt that this focus resulted in lower productivity. Nevertheless, we believe that this initial investment has paid off in the long term. The focus on clean coding goes hand-in-hand with clear instructions, allowing less room for guesswork and mistakes. It leads to a very structured software development process. Additionally, customers and users benefit from high-quality and testable code. That is because it is sustainable: clean software can be more easily adjusted and expanded in the future, thus reducing the amount of effort that is expended in the long term. Instead of a disposable product and the expensive process of launching software from scratch, developers can rely on a set of usable functions over the long term that ensure investment security. If developers incorporate the guidelines from the Clean Code book right away they can reduce refactoring and thus unplanned workloads. The code is less likely to contain errors if developers follow the recommendations to continuously test it. While the permanent productivity gains that you can achieve through clean code development are difficult to measure and prove, we follow Uncle Bob’s argument that the “life-cycle costs of chaos” can lead to zero team productivity over the long run if you do not care about clean code.
A propos Team
Clean code can provide a foundation for applying standards to code, and it can be used to stimulate discussions about how to create a common quality base that can be continually improved. Especially in the everyday life of a collaborative, agile, and growing team like ours, we have found it important to optimize the code for colleagues, who are new to the team or those who may have taken a new and complicated task from the sprint backlog that usually requires additional training.
However, readability is also essential for the original developer himself, because when code is written for long-term projects, it can seem new and unfamiliar when revisited again after a long period of time.
Optimized machine-readable code should only be the focus when it is really necessary, because “premature optimization is the root of all evil” (Donald Knuth, 1968). The fact that the performance of an application that was developed in accordance with clean code development principles suffers due to being broken down into smaller pieces in the code design stage is not a good enough argument for us to renounce the approach. Today, modern compilers have taken over most of the work to make code optimally machine-readable. The iterative approach and the need to continuously review the written code is deeply rooted in the clean code approach. Both fit very well with agile process models (such as Scrum), which our team lives by.
In the next part of the series you will learn what conditions must be established in order to implement clean code development principles on your team and how we have tackled this issue on the Cloudogu team. This first part has made it clear that both an individualized attitude to your daily work as well as team commitment and discipline, adaptability, and a willingness to learn on the part of all involved team members are key to capitalizing on the long-term benefits that clean code development can bring.