It’s inevitable that sometime in the lifespan of a software project, features that do not necessarily fit the overall goal will find their way into the code base.
In a world of online communities and open source projects, it’s really easy to get feedback from your user base and immediately think — “That’s such a really good suggestion, let’s implement it!” — without thinking whether or not the feature really belongs there, how many other users it will benefit, and what problems and inconveniences it might cause down the road.
Once a feature gets into its users’ hands, they expect it to be there forever, leaving you with two options: keep supporting it, or remove it.
The easiest decision, and probably the one you will first make, is to just keep it there, and make sure it keeps working, creating additional maintenance for you and your team, only delaying the inevitable.
Nobody wants to make unpopular decisions, but sometimes there’s just no way around it. When you decide that it is time to remove a feature, there are things you can do to help your users move on.
Communicate your decision. Explain why you are doing it, and why you think it’s best for the future of the project.
Put yourself on their shoes. If people use your software to make money, any features you remove can potentially have a direct impact on the way they make a living. Be mindful of their situation, try to accommodate them. Are there any other tools they can use to replace the feature that you are removing? Perhaps it will be a better fit compared to what you are currently offering them.
The next time you think about adding that nice and quick little feature, do some planning first. Talk to your users — their combined feedback will help you create better informed decisions, and remember, it’s also ok to say no. 🙂
Cover photo by Brodie Vissers.
Automattic Design 