How Stim uses Codacy to achieve high-quality code

We spoke with Tobias Sjösten, Head of Software Engineering at Stim, about how Codacy helps them guarantee code quality and standardization across teams and projects. We also covered how Stim uses Codacy Quality to deal with legacy code and directions for using Codacy Pulse.

About Stim

Stim is a collection society of composers, authors, and publishers, with over 100 000 members and music publishers. Since 1923, they’ve been working for solid copyright protections and guaranteeing their members get paid when their music is performed, streamed, played in public, or used in TV and film.

The main programming languages used by the Stim development team include Go and TypeScript. In addition, they use GitHub as their version control system. Stim employs a hybrid solution, hosting on CGP and on-premise servers.

Main goal: achieve high code quality

Stim has existed for a century, and they are here to stay. They understand the need to write high-quality code today so that their developers can more easily maintain it in the future. As Tobias explained, “The things we build must have a high quality because they will be around for a long time. They have to endure and be well-built so that they can stick around for decades to come.”

Dealing with a legacy system

Much of the code Stim developers need to work with was not written today but back in the 1980s in IBM RPG, a programming language that only a few people know nowadays. As such, Stim needed to modernize the technologies used to replace legacy systems, which included rewriting and refactoring portions of code and completely changing the programming languages used.

At the same time, Stim must stay competitive in the music world and keep evolving and creating new applications. As Tobias said, “We’re building new applications to take over functionality from the old systems. (…) But we are constantly trying to keep things up-to-date and modernized, with this delicate balance between staying agile, having the latest technology, and taking care of the old systems.”

Code coverage

In several organizations, legacy code also means that, besides the technological gap, developers wrote the code without tests. Code coverage, however, is vital to improving software quality by lowering the chances of releasing code with undetected errors and bugs.

Quoting Tobias, “When we started measuring things, on average, we were at 23% coverage of the 25-30 applications that were covered. Since then, that has grown; we now have 80 applications with test coverage, and the average test coverage has gone up to 64%. So it’s been tremendous growth in how we are testing our applications.”

But how much test coverage does the codebase need to have? For Stim, they initially aimed for 80% coverage, and they were strict about this threshold, blocking Pull Requests from merging if changes were below this mark. Although this threshold produced good results, they soon realized it was not ideal. As Tobias explained, “Initially, it was good because it gave us something concrete to aim for. But code coverage is a blunt tool to work with. It shows that 80% of the application has been tested, and 20% has not. But it doesn’t say anything about the type of code that hasn’t been tested. There’s no benefit in testing some code.”

However, the habit of writing tests significantly impacted Stim’s development team, positively influencing the code quality. As Tobias stated, “That’s also a huge difference in the code quality. Because if you want code that is easy to test, you have to write decoupled code. If you can break out this unit, you can test that individually from other parts of the application. And by doing that, you also get a better, higher quality application.”

Finally, developers learned how to test the code and incorporate it into their routine, even without the restriction. In Tobias’ words, “Right now, it’s like day and night, we have all gotten so much better at testing, and it’s a natural part of the development cycle. We have since even removed the requirements. And the tests keep coming in. So now it’s a natural part of our development. That’s a huge change in one year.”

Coding standards

Code standardization across teams and projects is one of the building blocks for the code quality that Stim aims to achieve, and Codacy helps them with this process. As Tobias stated, “There are a lot of different codebases to cover and track. So we need one central place to gather everything for one definition of a high-quality code base and one place to gather all the data to see what outliers we have.”

Codacy as part of the Stim’s development lifecycle

For Stim, Codacy Quality is a tool to empower developers and help them write better code. Regarding the development lifecycle, Codacy gives feedback on Pull Requests. Tobias explained, “We have a main branch; you branch out from that when you create a bug fix or a feature. You push that up to GitHub and create a Pull Request. (…) That’s where Codacy comes in, giving feedback on that specific PR.”

As a general rule, the new code cannot introduce any new issue. Plus, the feedback given by Codacy Quality is used to improve already existing code. So Stim implemented a triage process to address those issues, improving their code quality. In this process, one person per team is on triage duty, where they spend some time looking at critical issues and deciding if they’ll fix them now, if it’s something they shouldn’t fix, or if they should create a ticket about it. 

As Tobias told us, “Your [Codacy’s] issue detection has been very enlightening because some older applications had something like 43 000 critical issues. It’s impossible just to pause everything and fix all the issues. So we implemented something we call triage (…) We have seen that the issues vanish in the teams who have been good at it. And the code quality is very good. Just having this practice again has lifted us, and that was thanks to Codacy because Codacy identified it and gave us a useful list to prioritize.”

Finally, Codacy helps Stim achieve better code quality without getting in the way. It’s a very easy tool to use, and developers see the benefits of using Codacy. Tobias says, “It’s a very nice and sleek user interface. It looks great. It does everything you need. And people are very positive about it. No need to train developers, everything is very straightforward.”

Future directions for Stim and Codacy

The next step for Stim is to expand their usage of Codacy Quality and better configure the platform for their needs. They also recently started using Codacy Pulse. Pulse helps teams to measure the DORA metrics, allowing them to identify their level of performance in speed and quality of development. 

Pulse takes care of all the details to ensure DORA metrics – deployment frequency, lead time for changes, time to recover, and change failure rate – are accurate and reliable, allowing teams to achieve full engineering performance. As Tobias told us, “I’m super curious about Pulse because this year our KPIs are the DORA metrics. So that will be very interesting to look at as well.”

At Codacy, we’ll keep developing exciting products to help organizations like Stim empower their development teams. In Tobias’ words, “It’s great to see how your product keeps developing as well. That gives me some safety that we picked the right product as well. You keep developing things, and much of what you develop is in the direction that I would like to see as well. So that’s great.”

We look forward to seeing what Stim accomplishes in their mission of influencing policies and working for diversity and re-growth in the music industry.