This is a familiar tale; it isn’t at all unusual to find yourself in such a situation as a new person joining a project. Despite the temptation to refactor, don’t do so without a reason —-remember that any code you change or improve can introduce subtle or not so subtle changes in its behavior and can have unanticipated negative impacts on the business. It won’t matter that you wanted to make the code better, if you touched it you will end up owning subsequent blame for problems. Refactor when needed to cleanly add new feature requests or bug fixes.
The good news is that the team and code base are both small. Bigger teams and bigger code bases (like hundreds of thousands of lines) become non-linearly harder to repair.
Likely high level goals are: being happy at your job and making your company happy to have you there. As a new person on the team, refactoring on your own is perilous and probably won’t advance you towards these goals; so, what should you do?
Often, tangled code is paired with tangled development methods. Look for places to make useful improvements in the development process. Is the code and it’s data protected by adequate backups; is it under change control; is there a release schedule with documented testing procedures; is bug reporting and tracking done; are there specification, architecture, and design documents (under change control); are there tests; are there reviews and coding standards.
During this period of time, while learning the code base, you can make yourself valuable by helping with the process. Be sensitive to company politics and don’t embarrass people that could make your life difficult at this time.
If the company has a reason for or against using cloud backups, don’t try to change it, but if they don’t do backups properly suggest that you can dive in and help with it. If they are doing adequate backups, move on to look at their source control. I’d especially focus on ensuring that source code control (like git or Microsoft’s Team Version Comtrol) is being used. Help in the areas that need it the most first.
To introduce better coding you could ask the person in charge to “help you” by reviewing your code. This will allow you to talk about your ideas without directly challenging their existing code. Act humble, but more than that be humble about receiving suggestions for your own code. This will foster an environment where better code will be produced.
I was working on a big OS kernel project once, and a new contract programmer joined the team I was leading. He spent the first few weeks getting a better kernel debugger running, while keeping me up to date on his progress. Other developers started going to him to get help with their debugging and soon, he became that essential guy that everyone respected and needed. At that point, he was able to start suggesting changes to parts of the kernel that weren’t even his. Dispite the huge code base and the politics of numerous departments and hundreds of programmers, this person made many important improvements throughout the kernel over the next couple of years and was viewed as one of the most valuable developers in the organization.