Our Differences Make Us Powerful: Introducing the Clean Code Powerpack

One of the concepts that we created at FARFETCH is something we call the F-Tech Powerpack. You can think of our Powerpacks as a kind of energy powering the evolution of our development teams. Each Powerpack is supported by a self-organizing team of developers and focuses on a specific discipline or practice, such as Tech Talks, Flash Talks, Community Wiki Collaborations, Books Curation, Dojos, Mob Programming, Tool Reviews, and the focus of this article: Clean Code. 

"Even bad code can function. But if the code isn't clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn't have to be that way." - Robert C. Martin, Clean Code 

First of all, what is "clean code”? I created this Powerpack within F-Tech because when I build software, I’m always concerned about the quality, maintainability, simplicity, and readability of the code. 

I’m not necessarily an expert on the subject, I’m just an engineer with a passion and lots of opinions to share! I believe that the more you simplify your code, the easier it is to read. The easier it is to read, the easier it is to understand how it works. The easier it is to understand, the easier it is to debug and maintain.

I like to think of code as a work of art. Love and nurture it, take time to think through what you’re doing, and always keep in mind how it will look to someone else. Ultimately we spend more time reading the code of others than we spend writing our own code, so it’s worth investing time in improving its readability.

Code isn’t static. Seldom is it read and edited by only one person throughout the whole lifecycle of an application. Thus code is always changing, either due to new requirements or bug fixes. Clear and easy-to-read code reduces the maintenance costs and headaches for future changes. Who knows? The next person who needs to read and understand that code several months from now might even be you!

Just as a clean house invites visitors to take greater care of their surroundings, a clean and simple coding structure also encourages future code editors to take greater care of it. Messy code only encourages more messy behaviour.

Still not convinced? Think about how often you felt frustrated reading code written by someone else. Probably more often than you’d like, no? Remember this the next time you write code.

The goals of this Powerpack include appealing to good practices in software development and shared knowledge, discovering different approaches/solutions to solve the same problem, and, above all, learning. In the wise words of Albert Einstein, "Wisdom is not a product of schooling but of the lifelong attempt to acquire it". Learning is perhaps one of my favourite concepts here. Learning means evolving, and this is what makes us grow technically - and as a human being. 

Please avoid the temptation to learn alone. It is really important to interact with your team or with an expert. By sharing experiences and opinions, your entire team has the opportunity to learn something new. This is another objective of this Powerpack: to bring together people for a common goal. We want to encourage healthy discussions about common topics such as Test-driven development, design patterns, the structure of the code, architectural patterns, etc.

Inside each powerpack, we created a new concept we call the power plug.

A power plug is a person that represents the team in different guilds called Community engines aligned around Productivity, Growth and Innovation. This connection is essential so that these guilds can be put at work, fed by Powerpack outputs.

Experience within this Powerpack has taught me that everyone has different opinions. This is extremely healthy despite the potential frictions, because these differences enable us to build software with quality and fewer errors. One example of this was a discussion about the use of Extension methods in C#. Some people said that extension methods are useful for solution setup (dependency injection) and to manipulate lists or other types of objects. Others said they are particularly useful for replacing Helper classes that usually end up growing up as a "bag for stuff”. Different inputs like these can help us to solve a problem in our environment. Within F-Tech, we frequently diagram and document these options and their tradeoffs as "Decision Logs” in our Confluence documentation, allowing diverse stakeholders to contribute their opinions and perspectives. Once we’ve identified the best fit for our reality, we then adopt it as standard and try to build in as many efficiencies that can come with that. 

Technological evolution never stops. Hence at FARFETCH, as with any other organization, we must continue to learn and adapt. Sometimes that means adopting new technologies and figuring out how to best use them within our teams. Imagine a company that has exclusively used only one technological ecosystem when, in the course of their evolutionary problem-solving, they suddenly encounter a whole other world of software tools and practices, such as mobile developers using Java or data scientists using Python.

One of the biggest discussions within Farfetch concerned migrating our messaging protocol from RabbitMQ to Kafka. The change was large and far-reaching. We had to get FARFETCH ready for it, from infrastructure engineering to performance testing to developer practices. Introducing Kafka led us to adopt Java when previously C# was the dominant language within the company. This is because Java leant itself to easier implementations at first. 

Another major sweeping change at FARFETCH recently involved geo-distributing our data to reduce latency for our customers in China. This required us to rethink our system architecture and data persistence, creating several issues ranging from key generation to data consistency. Had the Clean Code Powerpack existed back then, many of these issues could have been addressed more effectively because it promotes common languages that bring specialists and non-specialists together, allowing them to brainstorm ideas and come up with the global solutions that consolidate the best ideas from everyone. In the special case of database migrations, the powerpack allows involved people to design a global data schema solution more suitable for the whole company as opposed to team data schemas.

Conclusion

Hopefully, these examples help illustrate how our concept of the Clean Code Powerpack provides value to the team; by helping us understand how we could adopt a new technology within our development ecosystem, how to identify the best guidelines to solve the problem, and how we can maintain the code as a solution to the problem. It's not about the inner workings of Kafka, Cassandra or C#. It is about finding a standardized pattern and model of working.

It also requires understanding how other companies successfully leveraged these technologies. After some investigation and use case research, we try to understand what are the best practices for our specific needs. It also isn’t a single person’s decision in isolation for how we should work with technology, but rather it is establishing a community of practice that draws in the diverse perspectives and opinions of our broader F-Tech team. This way of working truly reflects our ‘Todos Juntos’ company value - a Portuguese phrase meaning ‘all together’. 

Employing too many technology stacks makes it that much harder to train, recruit, and support a growing software engineering organization. However, by asking if we should restrict ourselves to a single technology, we are implying that this single technology can solve all our problems!

Any technology or language should not be chosen just because it is beautiful, because it is the most popular, or because it is what we are most familiar with. Technology should be chosen according to the problem that we want to solve and how it might fit in our environment.

Of course, technology evolves. Tomorrow you might find a better solution to this problem. You might also discover that the standards, design patterns, and business cases within your company have changed over time, making you reconsider a technology’s environmental fit in a new light. Thus it is essential to always be open to learning, to exploring new technologies, and to evolve your solution.