We have a project which had to be radically descoped in order to ship on time. It’s got a lot of code left in it which is not actually used. I want to clean up the code, removing any dead-wood. I have the authority to do it and I can convince people that it’s a commercially sensible thing to do. [I have a lot of automated unit tests, some automated acceptance tests and a team of testers who can manually regression test.]
My problem: I’m a manager and I don’t know technically how to go about it.
Any help?
I assume the question is how to find the code that isn’t being used, correct? The answer is a little different in different languages, but there are some general approaches. My very first job out of school was to find and remove tens of thousands of lines of unused code in a large shipping project.
The first principle is to focus on those things that are never called rather than just unnecessary. Finding and removing the former is a very mechanical and low-risk approach. The latter is a refactoring effort and a bit more complex. Always best to take out the easy stuff first.
Given that, what you want is part of static analysis, and there’s a large list of available static analysis tools on wikipedia. You should also search stack overflow for “dead code” and your language (C++, Java, etc.) This question has been asked a lot of different ways in the past. Generally you run a tool, see what it says isn’t used, delete that, then run the tool again to find the things that only dead code was using. Repeat.
From a manager’s point of view, you’re absolutely right here. The fact that you have a lot of unit tests means two things: you’re probably maintaining unit tests for things you don’t use (and that costs money), and the tests you have will let you make these kinds of mechanical changes with confidence. The best bet is to find someone on your team who likes to automate things; they often have the right mindset to do this kind of work. If you have multiple people working on it, I’d have one person learn the static analyzer and work out a pattern to follow. Then split up the team into different parts of the code so they don’t collide.
This kind of work can go very fast, and typically has a very good payback. Just make sure that people remove one piece at a time, compile, do some simple testing, and then commit that before moving on. Regularly (generally after a large change, or at least daily) do a complete clean rebuild and “big” test to make sure you really haven’t broken anything. The worst thing you can do is try to find every piece of dead code in the system and remove it all at once and then commit. I promise that removing one of those pieces will break the system, and you’ll never be able to figure out which one it was. But if you work methodically, this can be a very low risk endeavor.