As the tech world keeps evolving, having legacy systems is a certainty, especially for organizations that have been around for decades. Long-lived code, written many years ago, is running in production. This makes it harder to replace by a more modern tech stack.
In several organizations, legacy code also means that, besides the technological gap, developers wrote the code without tests. Test coverage, however, is key to improving software quality by lowering the chances of releasing software with undetected errors and bugs.
We spoke with Scott Anderson, Senior VP of Product & Engineering at Vevo, on how Codacy helps them replace a legacy system and guarantee code coverage.
About Vevo
Founded in 2009, Vevo is a leading music video network. They connect fans worldwide to a vast selection of premium content, from official music videos to live performances and original programming.
The main programming languages used by Vevo’s development team are Kotlin and Java. In addition, they use GitHub as their version control system.
Main goal: to replace a legacy system
Vevo has existed for more than a decade, and it is here to stay. Yet, maintaining 12 years of code is not easy, especially for an agile team that wants to remain competitive in the music world.
On the one hand, there is a lack of documentation that usually happens in software companies from day one. This is done to reduce the overall implementation time and accommodate the fast time-to-market of the early days. Quoting Scott: “The desire to move quickly and help the business grow was somewhat hampered by running the business on legacy systems that needed to be contained first.”
On the other hand, after 12 years, Vevo needed to modernize the technologies themselves to replace the legacy systems. This includes rewriting and refactoring portions of code or even completely changing the programming languages used. And this needs to be done while innovating in a global market.
As Scott stated, “We knew that we had a real opportunity born out of this challenge, where we had to rewrite this 12-year old software; we need to be really smart and tactical on how we do that work.”
For Vevo, these changes do not occur at the same time. Code is already in production, and there is little room for error. So, where to start? The changes are generally motivated by a new feature that might depend on some part of the already written code. As Scott stated, “We have a number of legacy systems, and the workflow around these does not always follow a specific order, my team and I are constantly prioritizing where we focus our efforts in the most effective way.”
Replacing legacy systems is just one piece of a maturing software company like Vevo. Code reviews, automated tests, and coding standards also need to become standard practice. Scott added, “We were focused on having a continuous delivery pipeline, so how we measured code quality, how we measured test coverage was key – further how we made our code review process needed to be as efficient as possible. We also had to build and improve our maturity around the development tools we were using – this added another layer of complexity but allowed for greater reward when complete.”
Code coverage – the path to follow
Code coverage is one of the building blocks of software with good quality. This is true, of course, if the tests themselves are meaningful and worthwhile. But, given that, how much test coverage does the code need to have, in reality? Scott told us the magic number for Vevo: “We tend to push for at least 70% across everything that we do.”
However, achieving 70% (or any other high number) might seem daunting when starting from scratch. As Scott confessed to us, “Because of the age of some of the software and systems we are working with we might need to think that number on occasion, we might say – ‘Okay, now we need to have 80% code coverage’ they’re [the engineers] gonna spend a month working on it to really get this right.” We understand the pain; it’s a complex and time-consuming process.
So, how can you do it? It can be helpful to deal with the legacy system gradually, piece by piece, and have milestones along the way. As Scott said, “As we’re replacing a legacy piece with something new (…) we have a baseline standard. And then we have our target standard. That way of working really allows us to get something started and working, and then gradually sort of increase the thresholds for what it is, and we find that suits our needs well.” We all know the story: slow and steady wins the race.
This step-by-step approach and the target for code coverage are also beneficial for planning Vevo’s development roadmap. The analysis of the legacy systems drives decisions and helps in prioritizations and allocation of resources. As Scott explained, “(…) when we are building something that is going to add value to Vevo, we look at the legacy systems we want to replace and review them – analyzing how close or far they are from that threshold can help with timelines and help us understand realistically how long things might take – instances where cleanup or the work on test coverage.'”
The work is not over, but the advantages of achieving code coverage in some parts of the system are already evident. Codacy helped Vevo substantially reduce the support time and avoid fires. Scott added, “A lot of our YouTube publishing pipeline is now covered through this. (…) it hit 70% code coverage across those pieces, and we’ve reduced our tech support time by about 60%. For most of these legacy systems that had outages or blips on an almost daily basis, we’ve reduced that significantly, to where we are not in rapid response or firefighting mode all the time.”
New pieces of code follow the code coverage lane
As we saw before, Vevo is taking care of the legacy system. But Vevo is constantly developing new things, so what is the company’s approach to these new pieces of code? As Scott elegantly put, “They’re building the legacy software of the future. That’s what they’re building today. And they should leave it in better hands than they found it.”
Given that, code coverage should also be a concern for today’s code, not only for legacy systems. New projects can benefit from it and make life easier for the developers. As Scott said, “As we build out new pieces, we’re doing it in a very modular way. Codacy, it allows us (…) to set new standards for our code coverage to make sure we’re doing a good job testing.”
Since the changes happen when working on particular pieces of code and new development follows a modular approach, Vevo needed a solution allowing for customization. In fact, the flexibility of Codacy allows Vevo to focus on repos that are more important at the moment. “I think something about Codacy that the team really likes is the customizability of the configurations per these modules where it’s not a cookie-cutter standard (…) So they [the developers] can customize what they’re doing individually, as long as it hits a standard that we’ve set as a team.”
Change developers’ behavior to get a green light
Developers are pleased with Codacy and they understand the time needed to invest in code reviews. Using an automated code review tool allows developers to write their better code while maintaining peace of mind. They know that Codacy will flag them if something goes wrong. As Scott noted, “Engineers don’t feel like they’re wasting their time doing code reviews because they look at a PR and review. The code review process has been really one of the key things where it’s really improved our efficiency and our cycle times and how well things work.”
The usage of Codacy can even influence behavioral changes from developers. As Scott commented, “obviously, that tends to drive behavior changes (…) once you integrate it [Codacy] because they (…) want their stuff to be green, and they want it all to go through successfully.” Since maintaining the standards is so important, if something causes the code coverage to go down, Codacy blocks it. As such, developers want their code coverage to be better.
While the Vevo development team grows, Codacy can also help with the onboarding process of new developers. It can be beneficial for juniors who are still learning how to navigate the software development world. As Scott explained, “(…) in those cases, you definitely want to have a little bit more support in place. So that they’re given guardrails, and they can work and be free, but the tools can kind of tell them and reinforce some of the behavior again, without it always having to be the other engineers.”
Future directions for Vevo and Codacy
The next step for Vevo is to expand their usage of Codacy to even more teams working on different projects. It’s also time to aim at bolder goals and unlock the full potential of using a tool like Codacy.
As Scott told us, “It’s really about expanding this across our other platforms where we’re running continuous deployments all the time. Now that we see what’s possible [with Codacy], we’re going to go into 2022 with a focused goal. (…) We’re budgeting a certain amount of engineering support time out of that team every two weeks. So as I look to 2022, I will think about how we get that down to half, so that we’re running the same software, we’re spending less time fighting fires and supporting it, and more time building cooler stuff that really adds value to user experiences. And Codacy is part of that story.”
