When a friend of mine made a Google+ post a while back asking StackExchange what happened to the links to post your question on Facebook, Twitter, Google+, etc., he learned that the links were removed because they were hardly being used. This led to a brief back-and-forth thread between him and me on the post about the propriety of removing old features that just aren’t as cool as they used to be. Long story short, I’m in favor of cutting the links (and removing unused features in applications), he was opposed.
Now, before you “You don’t remove features ever, at any time, for any reason – no exceptions!” purists really get your hackles up, let me clarify a few things. Your default behaviour should always be to leave a feature in. Removing a feature is a serious decision that should only be made after a long and hard discussion about how many of your users use it, how important it is to their use of your software, and how you’re going to accommodate that workflow once you remove the feature.
The cold hard reality of software development is that if you put a feature into your software, some subset of your user base is going to use it. As a result, taking away a feature is some pretty basically akin to buying something from a vendor, and then at some point in the future that vendor marching in their house and taking it away. This should give you a rough idea about how committed you’re going to need to be about taking away a feature to consider it a good idea.
Assuming you’re still signed on to the principle of culling features from your software, you need to figure out if the feature you want to cull should be removed in the first place. First off, you need to be absolutely certain that this feature is getting minimal use. That means, “Who still uses that?” and “People still use that feature?” are not acceptable reasons for removing it. Remember the analogy from earlier, you’re kicking down these people’s doors and taking their toys. And when you’re in the door-kicking, toy-taking business, the more people you impact, the angrier the reaction will be. Make sure you know what percentage of users still use your old, outdated feature, and what number of users that is (Remember kids, a little percentage of a really big number is still a big number!). If 5% or more of your userbase is still using the feature, leave it, it’s not as dead as you thought it was. I can’t give you a handy-dandy rule like that for raw numbers, seeing as how it’s a judgement call based on the size of your userbase, but assume that if the number sounds bigger than what you were expecting, the correct answer to the question of “Should we delete this?” is “No.”
OK, so you have some feature that’s certifiably worthless, and no you know for a fact that nobody’s using it. That’s still not a good enough to just yank it away from people (kicking down doors and taking away toys is considered a mean-spirited thing to do after all). Your software should be better when the feature removed than it is with the feature left in. Otherwise, leave it alone. In the Stack Exchange bit that started this whole ordeal, removing the social network cleaned up and decluttered their user interface. Now there’s less stuff distracting users from questions and answers.
But that’s a specific example, in a more generic sense, if leaving a feature in doesn’t hurt anything, don’t take it away. I’m going to go out on a limb and assume that Stack Exchange didn’t yank these buttons the second they noticed they weren’t popular. It’s safe to assume that people hadn’t been using those buttons for a while, which begs the question of why did Stack Exchange finally decide to remove them? My best guess was that Stack Exchange was maintaining the social network buttons and using the social networks’ APIs. While I don’t follow social network APIs closely, I’m guessing keeping those buttons going was getting to be a lot more trouble than they were worth for the handful of users actually getting something out of them. My theory is that developers were wasting time keeping these things working when they could have been making Stack Exchange more awesome.
This brings me to another point about removing features. Very few features have 0 users, which means even though there’s not enough benefit to people to justify keeping it alive, you still have to offer the feature’s holdouts something to make up for the functionality you’re taking away from them (and probably apologize for kicking in their door too, that is kind of rude). Otherwise, removing the feature makes your application less valuable to your users, and that’s a terrible plan for staying in business. The users that were using whatever feature you took away are going to be angry (door kicked in and all). You need to deal with this loss proactively to help convince users that your software really is the better for what you did. No matter how rarely used something, the fact that it’s used means your users are going to be mad that you took something away from them. Offer them something up to show that you can still help them solve their problems, and it’ll help ease the pain you’re causing them.
Removing a feature is serious business, and it’s not something you should do unless the feature becomes more trouble than it’s worth. That means it’s not adding value to your users, and the users involved are largely negligble. You also need to know how you’re going to make up for this. Removing stuff people find useful isn’t something you should do if you can find any rational justification for leaving it in, but you can’t be completely unwilling to cull dead weight in your code. That just leaves users with bloated software full of crap that’s of no use, and developers with huge code no one uses that they have to waste time guaranteeing will still work because some tiny minority still comes across it. Sometimes, you have to make the tough decision to put a feature that’s long past it’s prime down. It’s hard, but that doesn’t change the fact that on rare occassions it’s what’s best for everybody.