[cesaref]

Well, let's say you are working on a well engineered and tested product, and you look at the code coverage, and there's a whole lump of functionality that has no coverage.

You could conclude that the code is unnecessary and remove it, or you could conclude that some test cases need to be added to exercise it. How do you decide which is correct?

The problem is usually that well thought and and designed software was build for a moving target, and invariably things have changed over time. It's not necessarily a sign of lazy design, it's where the real world intersects with the nice neat pretend world we design for :)

[convolvatron]

I'm deeply frustrated at the missing answer here. read the code. figure out what's it for. take out it and see what breaks. software is not a house, you can completely wreck it and set in back exactly the way it was in a second.

there is no excuse for not owning and knowing the software you are supposed to be in control of.

[cesaref]

Well, if it isn't covered, then you can take it out, and see what breaks (nothing) and then discover in production why it was there :)

But yes, it's basically what the job comes down to - having a strategy for managing complexity in all it's forms, and this is a fine example of the sort of problem that you don't learn in college.

I've (thankfully) never deprecated code and caused serious production issues, but i've seen it happen. The best places to work expect this sort of issue, and have process in place to roll back and deal with it, like any other business continuity issue (e.g. power/network loss).

The moment you find yourself scared of changing code because you don't understand the consequences then you've basically lost the battle.

[convolvatron]

hopefully there is some other place to try your code than in production. that gives you the agency to say "lets just take it out and see what happens".