I've been working in an application with about 100k LOCs and basically We have been reworking features to comply with a new architecture based on a new technology stack. This work is almost finished but we had to keep the old code because we had to guarantee a stable environment in case of critical bugs in the new .
This has lead to a situation where we have a lot of dead code that mixes with a lot of working code thus making difficult to estimate how much time it would take to remove this dead code.
This codebase in particular is very troublesome as it does not have unit/integration testing other than the one generated in the process of reworking the features we migrated to the new architecture and also I think that a great deal of the new code is interwoven with the dead code (by static calls, using the previously thrown exceptions).
What would be a good start point to estimate how long would it take to safely remove the code?
Best Answer
Each project is going to be different so there is not an effective way to estimate the time to remove dead code. Needing to keep the old code sounds like you lack a quality source control system that allows you to branch.
In any case: Tools like SonarQube can help identify some dead code, but won't find things like a class that is never used. I would suggest tackling a portion of the code by hand with the help of SonarQube and develop estimates as you go. If you work through 20% of the classes and it takes 2 weeks then you can estimate an additional 8 more weeks to do the rest.
Also, having some sort of automated testing will help prevent you find code that is mistakenly deleted faster.