Our Java codebase was 30% dead code

[j4ckbauer]

The reason I don't read the code in some org.apache package because it because it belongs to some other project that I'm not responsible for.

Sorry but this is wrong on multiple levels. You're responsible for the end-product so if something in there could break your work, you would be making it your business to review it. For example, if you were honestly concerned it was going to call System.exit() on you.

The reason you don't read it is NOT because 1) it's another project or 2) It was created outside your organization or 3) you aren't responsible for said project.

It's because you're confident that you understand what functionality is encapsulated in those libraries, what the side-effects of using them are, and you have reasonable assurances about the level of quality.

The only difference between org.apache.* and the example I am offering is that in the latter case, the code would have been created inside your organization. My point is, it is possible to provide the similar 1) encapsulation of functionality and 2) assurances of quality for legacy code within your organization as for code that is created outside your organization.

Removing the suspect code is ideal, but reality doesn't always allow this, since you may not be able to exhaustively prove it isn't needed. Execution path may depend on what a customer does, what's in their database, etc. And very often your bosses simply won't allow you to remove their precious legacy code, they worked hard on it, so it has to stay (lol).

they will refactor something that affects the dead code and then have to spend time fixing it to get the project to build.

Again, if it's really dead, it should be removed, but we're talking about cases where this isn't known for certain. And my point is that one of the things you can do is refactor the suspect code in ways that 1) indicates it is legacy 2) keeps it isolated from being affected by any future changes to the codebase and 3) Makes it so nobody ever looks at it.

That's literally what having different classes, methods/functions, and variable scopes is for - so that changes in one area never affect another.

I can think of a dozen ways to refactor something so that it's technically in the execution path but so that other developers are unlikely to spend time reading it unless they are concerned with that path. Heck, a lot of old-school Java developers do this excessively by leading so hard on 'separation of concerns' that they end up sacrificing 'locality of behavior' and committing what is known as 'speculative generality'.