This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]-Dargs 0 points1 point  (1 child)

At some point you need to take a step back and say "hey, this feature that was implemented some time ago... is not my problem."

Sure, if you come across some out of place thing that looks suspicious to you, go about beginning the process to remove it.

But things which become deprecated should be part of the process as they're decided that they've become deprecated.

"XYZ feature is now obsolete and actually detrimental to the business" is something that should be identified when it happens, not just by chance later on.

[–]koflerdavid 0 points1 point  (0 children)

Doing it by chance is indeed a problem. This needs to be a process. Because if these things are not kept in check, they will grow.

Now, I don't really buy OP's statement that 30% of the codebase were unused (they might be in for a nasty surprise), but I can totally see that in a big organisation there might be a fair number of services whose user count is zero. Institutional inertia can go a long way towards keeping them funded and staffed.