From the course: Agile Software Development: Dealing with Legacy Code and Technical Debt

Take ownership

- [Narrator] When you inherit an older code base, it's important to realize that it's now yours. Any of the bugs that are found are going to be your responsibility to fix. And any new features that need to be added will need to be added by you. It can be tempting to simply complain about all the decisions that were made differently than you would have made them. Instead of doing that, it's much more productive to simply embrace your ownership of the application and take charge of it. Let's consider a simple example. Say you open the project and you find a bunch of files that are formatted differently than you would have formatted them. In some cases, the difference between your preferred formatting and the one in the code is so different that you're finding it hard to read. How should you handle that? One way would be to force yourself to read the code the way it is. This approach will likely slow you down and frustrate you. You might even make mistakes because important, subtle details are hard to spot. You could be tempted to blame these mistakes on the people who came before you and keep suffering through. A better approach is to just reformat the code so that it's easier for you to read. It doesn't matter that your preferences are different than the original developer's preferences, they are not working on the code anymore. You get to make the decisions about how things should be formatted, and it makes the most sense to pick a format that works best for you. This kind of approach works for more than just the simple things like how to format chunks of code. It's important to adopt this way of thinking for other aspects of the application as well. You don't like the way a part of the system is architected? You can change it. Don't like the version of a library that's being used? You can upgrade it. Don't like the testing tool that's being used? You can switch to a different one. The important thing to remember is that you are in control. You have the power to make the code better, and you get to decide what that means to you. The project is yours now, own it.

Contents