The team

Three year ago, my scrum team became, officially, a scrum team dedicated to the SAP Localization Hub Tax Service, a tax computation engine on SAP Cloud Platform.

Our team, as expected in any team, is composed by a set of people with different knowledge and skills. Not only that, we also differ in terms of generations, the SAP Labs Latin America is located inside a university campus in the south of Brazil, therefore, we have in our team’s DNA the youth of newcomers as well as the experience of ancient developers.

Of course, we see this diversity as a positive aspect of our team as it brings several perspectives to discussions and increases our chances to consider all the aspects that are required to build software. But, having people with such diverse backgrounds in our team implies a diverse style of coding in a project, sometimes even in the same context (classes or methods). “So what, Is this a problem?”

Houston, we have a problem.

Well, in a sense, yes, we do have a problem. Reading code is just like reading a text in “human language”. Imagine you are reading a paragraph written by Douglas Adams and in the very next paragraph you find a Shakespeare like sentence. It requires more attention and increases the difficulty to understand what is being said. As we all know, bugs are stealth masters, they sneak into the most unexpected piece of code, therefore, the most you spent focusing in understanding the code the least you are focusing in finding the bugs.

In addition, building a cloud service is already a challenge by itself. You don’t have the luxury to allow technical debt, you must automate any kind of repetitive task, and you need a safety net to avoid broken or unexpected behavior, just to name a few. You must do all of that to achieve the basics of the highly competitive cloud market.

So, we, developers, have many important things to worry about and yet, we spent most of our time reading code and learning with it. Knowing that, we wonder: Can we improve the experience of reading code by reducing the amount of code styles in our code? Well, to improve the reading, we certainly must improve the writing.

Building a Clean Code Culture

Our very first attempt to improve the way our code was written was by trying to be more rigorous during our code reviews. In our code review we use Github Pull Requests(PR), where one person is assigned to review and provide feedback about the code before it is merged into the project. This approach first led reviewer and author to initiate discussions about whether the code was readable enough or not. After that, they have the result of the review session documented in the PR, and therefore, they made it available to everyone in the project.

Our expectation was that by discussing the best ways to write code and documenting it in the PR, everyone would be able to access and learn with these decisions and consider them in further discussions. Therefore, creating a snowball effect. Well, the true is that by the end of the code review, usually, only the reviewer and the author knew about the outcome of the discussion. Other developers that were not involved would not read the PR and therefore would not be aware of these discussions.

So, yes, we started to have improvements in the code we were writing, but we needed those changes to happen faster. Learning with your own mistakes is good but learning with someone else mistakes is better. Who did mistakes enough that can help us now?

Faster, Faster

We found the help we needed from the Clean Code book by Robert C. Martin. The book itself is no news and it has been published a long time ago. Its content describes in a didactic and updated way how to write clean code. A new book club is created.

The whole team agreed to read a book’s chapter every two weeks, and at the end of the second week we would gather for one hour to discuss about that chapter. Also, we asked the developers to look for good and bad examples in our existing projects and bring these examples to our gathering.

Every meeting, the host starts asking “What did you think about the chapter?”. This question makes people think about what they read and share their understanding with the whole team. As people assimilate knowledge differently, other concepts that were not covered by the book were also brought to discussion. This led to suggestions for other articles, videos and to other books that we intend to read after we finish the Clean Code.

Smells like team spirit

It’s difficult to measure the impact of the club with numbers. However, it is a general feeling that code reviews are more focused on business and design decisions rather than discussions about code intention. This feeling is probably related to the fact we are reducing the code styles and converging to our own and unique code style.

This code style is the outcome of the discussions we are having during the past months in the club. It’s the set of practices that we discussed and agreed with and although they are not documented they are part of our team’s culture.

End of the Road

With few hours every two weeks we are increasing our team’s productivity, improving the product’s quality and getting even better technically. This recipe went so well we already had it “copied and pasted” to other scrum teams here in our location. And their feedback is also very positive.

Not only that, we also used the set of bad and good examples we gathered from our club’s discussion and add it to internal trainings about Clean Code. So, we also hope to be helping other SAP’s colleagues around the world with this small initiative within our project to improve our reading experience.