views:

144

answers:

4

So, 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?

+4  A: 

make sure it's all checked in to your source-control system and tagged as a specific version (prerelease or something you can remember)

back up the code onsite and offsite

run a static analysis tool over the code to identify the deadwood

delete the deadwood

rebuild and re-run all tests

or you could just ignore it ;-)

Steven A. Lowe
if it ain't broke, don't fix it! ... +1 for sound advice on both the 'dogmatic' and 'pragmatic' approach!
lexu
However, I pose that dead code is broken code: while the application as such works with or without, the dead code adds extra work for your developers, especially over the long run when the old hands move to other projects and new devs struggle to understand the application.
Lars
Thank you Lars. I constantly encounter hopelessly convoluted code developed by people too afraid to actually fix code they don't understand, and endlessly trying to find the least risky change that will deal with "today's problem." The adage "if it's not broke, don't fix it" often leads in practice to ever-more-fragile and unmaintainable code. This does not suggest that constantly rewriting working code is a good idea. Martin Fowler has written a lot of good stuff on when you should and shouldn't rework "working" code. But removing unused code should be a no-brainer.
Rob Napier
+2  A: 

I don't think there is any easy way. One idea I like is to write fairly complete automated acceptance tests, and then use a coverage tool to see what code was not exercised.

Kurt
+4  A: 

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.

Rob Napier
+2  A: 

First of all, I'm assuming that your code is checked in to some kind of version control. If not, you have much deeper problems than unused code. Given that, just follow the advice of this link and delete it.

tikiboy
@tikiboy - i don't have the heart to downvote you. But you might consider deleting this ridiculous answer to a serious question.
Sky Sanders
@Sky, thanks for not downvoting me on my very first post here. I didn't mean for it to be a ridiculous answer and the question itself is somewhat vague. It's possible that the link I referenced was not visible enough and I've edited my answer slightly to make it clearer. The link itself addresses something I sometimes find myself doing - not being able to actually delete code. It may not address the question exactly, but as I said, the question is a bit vague. If you still feel that this answer is ridiculous, well then downvote away.
tikiboy
@tikiboy, the OP doesn't have a problem pressing the delete key, he is rightly concerned with breaking the build and is looking for guidance on how to go about this responsibly. For small applications, this is a trivial task, but in a larger scope it can be a source of anxiety and lost sleep/work/JOB. So - maybe not ridiculous, but doesn't really address the OP question and might be construed as being flippant. my .02 pesos. Welcome to SO.
Sky Sanders

related questions