For those who have never been involved in software development, even the most sophisticated often think of code as lines of text that magically create an outcome. It is easy to think of developers as factory technicians, moving software down the assembly line, putting each piece together the same way every time.
While efficiency and consistency are crucial, coding is not just an assembly line. Instead, it is a craft, with basic rules and functions, ultimately providing the developer with the latitude to make decisions both functional and aesthetic. Achieving the desired outcome is a function of these decisions. In that way, even at scale, coding is much more akin to carpentry or blacksmithing than to manufacturing.
Because of this leeway, however, the pursuit of quality standards becomes incredibly important. How do you as an individual developer know that your code is “good?” As the development team grows, how do you maintain that standard across several, or hundreds, of individual craftspeople? This is a question that is continuously debated by engineers at all levels of an organization.
At Codecov, we’re dedicated to providing resources to help answer these questions. Testing and code coverage metrics are an important, objective means of providing insight into code quality, but not the full picture. Because of this, we are constantly working to understand how our users view code coverage and its utility within their teams.
One of our most important insights is that code coverage, and in fact, code quality measures generally aren’t just about creating good process. Equally important is creating a mindset that thinks deeply about how code is being written, as much as the problem that code is trying to solve. The cultural element of code quality is often as important as what code quality achieves procedurally.
For many Codecov users, this manifests as a team wide pursuit of 100% coverage across the full code base. That pursuit incentivizes and gamifies thinking through how code is structured and how it will affect the code coverage metric. In doing this, developers often uncover issues earlier in the process.
Certainly the pursuit of code coverage metrics will not ensure a bug-free product, and other means of ascertaining code quality, such as code reviews, are incredibly important. However, the cultural significance of pushing for particular achievements, especially objective achievements like 100% code coverage should not be underestimated.
Culture takes many forms within teams, but it starts with the way that each individual approaches the work and the team. Creating a culture of quality isn’t necessarily about creating rigid structures as much as setting a goal that the whole team is striving to achieve. When the goal is clear, every step from preparation to execution can take it into account.
When each team member has their eye on the prize, that focus on code quality can lift their work from the very beginning and create better outcomes in the end.
