You should never remove code that you don't understand. And when isn't it a priority to "not break anything?"

Whenever your product is in for the long run. For those cases, better temporarily break it than eventually being unable to manage it at all. That line of code no one understand is a technical debt. Sometimes, it is better to pay the debt right now.

I'm currently working on a 2 millions LOC program which never paid its dammed debts, and I weep every day before this holly Big Ball of Mud.

If our highest priority was always "Don't break anything", we would never ship to production after the first move. "Make it better" is often a higher priority.

Yes you should. It is often the simplest way of discovering why it is there - you see what part will break.

I think you mean this as part of the investigation in what this code does.

That is, after setting up a test/dummy system, you remove the code, run your tests and try to break it. Perhaps sticking in breakpoints or print lines or whatever..

I doubt you really mean to experiment on the business-critical live system.

Thats unlikely to be very effective anyway. The most obscure code is often a bug fix for some really obscure bugs. Maybe it fixes some weird bug in Swedish XP SP1, or something which you don't find just by removing it and testing. Situation depending, you will need to actually read and understand the code and investigate properly.

Obviously, it is not a tactic to use on a live production system. On the other hand, no programming at all at a live system is the prudent way of doing it.

Good test coverage help a lot here though - remove something and you'll get a set of failing tests to investigate.

Or you notice nothing breaks so you leave it out, joyfully congratulating yourself that you reduced total LOC count by one. Then six month later things start breaking and you have no idea why.

Refactoring and removing code needs courage and tact, but sometime it needs to be done. If you have a database that is not properly normalized, the more client code you add to it, the harder it is to normalize later.

The biggest problem with refactoring and removing code is to explain it to non-techy project managers. If you say that the code or the design is bad, you are saying the guys behind it are bad (you or the previous team), which is not very tactful. I usually try to explain that a software system is a living thing, that need some regular washing up. Also, it is possible to explain that the next features or optimizations will take less time to implement after refactoring.

I tend to blame myself. "I didn't fully understand the problem space when I first wrote it, and now I have to rewrite it because it is a horrible mess and too complex to maintain".

Works surprisingly often.

"You should never remove code that you don't understand."

Never is a long time.

It's fairly easy for low-skill developers to write code that's time-consuming for high-skill developers to understand. In fact, making simple things hard to understand is pretty much the definition of bad code.

So, you use your judgement. If it's a particularly subtle and important part of the code, spend the extra time to make sure you're not missing anything. If it's not, then just rip it out and don't waste time in a maze of strange control flow, redundant code, useless invariants, and confusing assumptions.

> If the priority is to not break anything, sure, don't fix what's not broken.

The issue generally arises because things are broken, investigation leads to a piece of code which creates the breakage (everything is perfect before, things are broken after), nothing seems to use it (the project is naturally pretty much void of automated tests), you remove the code, it fixes the issue, and then you learn that prod has started failing hard.