[MUSIC] Refactoring code is a really common part of software development. Software design practices evolved tools for instrumenting and debugging code change, and most importantly, the use cases for a code base will evolve over time. So code written without extensibility, testability, and maintainability in mind often needs to be refactored. My team has a component that is both server side and component side, and over the past year we've been refactoring both of those. For the server side the legacy code base was really old. It was written by someone who was no longer on the team, in fact the team had turned over a couple times. It wasn't well commented, so it was really hard to understand what was going on in the code and how it worked. And so we couldn't really add new features, or really even debug any issues cuz it was so hard to understand. We refactored it to be modular, to have better logging, and to have a more extensible architecture. The application performed several functions and so throughout the course of last year we replaced each one of those functions with new code. The advantage of replacing one function at a time is that it allowed us to validate the new design with real traffic in production and have limited scope to debug and troubleshoot any sort of issues we ran into. If we had rewritten the whole application in one big bang and found there were performance issues or a lot of bugs, it would've been really hard for us to troubleshoot. We've also been refactoring our client code to increase testability. Our original code was written without test coverage in mind. So we've taken on an initiative to increase our test coverage to a very high level. In order to do this, many of the classes actually need to be rewritten, or refactored, because they weren't written with testability in mind and so there aren't hooks for us to actually wrap unit tests around the classes. I think this is a really common practice that people wanna launch suffer really quickly, and as a result you take a penalty, you incur this technical debt. So you have to really think about that when you're trying to launch software and balance long term maintainability with the software with time to market. It's a natural human tendency to prefer our own coding style to other people's, we have to be really careful not to refactor just because of the not invented here syndrome. Just because the code doesn't look like the code you would've written, that's not a very good reason to refactor. Instead, we only refactor when we have something that's gonna be a tangible benefit or a tangible positive impact to our users. So we often refactor when we need to be able to add more features, when we want to be able to resolve issues more quickly, or we wanna improve the quality, we never re-factor just because.