Clean Code at Different Size Companies
How Resourcing Affects Clean Code Standards
Clean Code is a set of guidelines for writing code that is easy to read, understand, and maintain. However, the emphasis on clean code depends on the size of the company.
In this article, I will cover how the size of a company affects its coding practices. Then, I will provide practical steps on how to implement clean code practices in your own work.
What is Clean Code?
Before comparing clean code at different size companies, we will need to define clean code. Clean code is code that is easy to read, understand, and maintain. It follows a set of coding standards and design principles that aim to improve the quality of the codebase and make it more resilient to changes and updates.
Clean code can be characterized by:
Readability: Code should be easy to read and understand, especially for developers who are not familiar with the codebase. We can standardize variable, function, and class naming.
Maintainability: Clean code is easy to modify and update, as it is modular and well-organized. It follows established design patterns and practices and avoids unnecessary complexity.
Testability: Clean code is designed in a way that makes it easy to write automated tests, which helps ensure that changes to the code do not introduce bugs or break existing functionality.
Clean code is important because it can reduce the time and effort required to develop, debug, and maintain software. It can also improve the reliability and stability of the software, as well as the productivity of the development team.
Impact of Company Size on Clean Code
Clean code has huge benefits for software development in any size company. Unfortunately, smaller companies do not prioritize clean code. Instead, they focus on proving their business value to current customers and to onboard customers. Innately, the goal to provide business value is not a bad choice. However, when the focus on business value continually triumphs over clean code, we get into a problem.
I will walk you through a commonly seen and definitely oversimplified scenario. The product team wants a feature to be added to the application and aligns the timelines with software engineering. Software engineers implement it. The product team will come to us, the data team, and ask how long it will take for the data to be published to their X dashboard. This is the business value cycle.
In most smaller companies, this cycle becomes rather vicious. The product team wants to see the results faster, encouraging software and data engineering teams to make decisions that are not always in the best interest of long-term product health or data pipeline health.
Smaller companies’ focus is short-term, and they will neglect the data pipelines if it means they can see the business value more quickly. Honestly, who knows if they will survive it past X period?
Meanwhile, larger companies place a higher emphasis on clean code. They know that they will be around in the long term, so they will ensure that code is treated with the respect it deserves. Treating the code with respect means that we ensure that the new code adheres to clean code standards and that we will be actively decreasing the technical debt.
Of course, not everyone has time spent to decrease technical debt. However, we can at least treat the new data with respect. How can we do that?
Practical Steps to Limit Technical Debt
We cannot fix technical debt overnight. I know that. You know that too. But what we can do is limit the technical debt added to the code database.
Use version control
You would be surprised at how many data engineering or science teams are not implementing version control. Version control makes life so much easier as we have a record of what code got changed (think about those bugs you could have reverted!) and automation.
Define and then follow good coding practices
Sound familiar, doesn’t it? But seriously, make sure that your team is in agreement about what clean code means for your code database.
Automate your formatter and linter in version control
Automation makes the implementation of coding practices a lot easier e.g. GitHub actions can run pep8 or black every time you push code.
Conduct regular code reviews
Have other team members review your code to catch any issues or potential problems before they become more serious.
Use automated testing
The types of testing that we would want to focus on are unit tests and integration tests for data engineers. However, I have added system tests and performance tests for your information.
Unit tests: Unit tests test individual units of code (usually functions or methods) in isolation from the rest of the codebase. They are used to ensure that each unit of code is working correctly.
Integration tests: Integration tests test how different units of code work together. They are used to ensure that different parts of the codebase are correctly integrated and functioning as intended.
System tests: System tests test the entire system as a whole. They are used to ensure that the system is working correctly and meets the requirements of the project.
Performance tests: Performance tests test how well the system performs under different conditions. They are used to ensure that the system can handle a large number of users or a high volume of data without experiencing performance issues.
None of these practical solutions will work if we do not add the key ingredient to a successful team—a safe place to make mistakes.
Psychological Safety
In Chapter 7 of The Art of Agile Development, Gitte Klitgaard defines safety as a place where team members “are safe to disagree with each other” (p. 95) and will often exhibit these types of behaviors:
Team members speak up about mistakes and what they’ve learned.
Team members disagree constructively.
Team members bring up ideas and problems.
The team creates better products that incorporate more ideas.
It’s easier to hire and retain people with diverse backgrounds.
How to create safety within a team is an experiment in itself as the feeling of safety does not look the same for everyone.
How can I create safety for my coworkers? Gitte Klitgaard suggests that we can start by practicing these behaviors.
Enable all voices
Be open about mistakes
Be curious
Learn how to give and receive feedback
Use empathy
Allow yourself to be vulnerable
I, to be honest, might not be the right person to define what these behaviors are as I continue to struggle with them. Regardless of my shortcomings, I want to emphasize that I and your team members need folks to “care personally, and challenge directly” (Radical Candor). We can only know then what mistakes we have made or how to fix them.
And most importantly, remember an apology goes a long way.
Final Thoughts
A safe work environment allows us to openly discuss our mistakes and take steps to prevent them from happening again in the future. Without open communication, a small issue now could become a larger problem down the road, especially in smaller companies without established systems in place to prevent problems. By fostering a culture of openness and honesty, we can identify and address problems before they become bigger issues.