The business reality is when a feature is added, there's almost no way to remove it, because the result would be less money to pay salaries. Hopefully the benefit would result in more than 10% of additional sales with better features and changes.
The business reality is when a feature is added, there's almost no way to remove it, because the result would be less money to pay salaries. Hopefully the benefit would result in more than 10% of additional sales with better features and changes.
I certainly would not say that we "strive" to make any feature go away. In some cases, though, a certain feature can actually prevent us from implementing new functionality. It's always a tough decision. We don't want to leave any customers behind, but at the same time we don't want a small minority of customers preventing us from moving forward either.
I don't think these kind of decisions should be left up to a lone developer to make on their own. The developers, sales, support, management and everybody should be working together to understand our customers and what our mission is. It's not easy.
It was just an example.
> what if removing that feature means that 10% of users who use it are no longer paying customers?
I can think of scenarios where that feature for 10% of customers is causing issues for rest 90% of customers, or eating up all the support time or ops teams' time.
> The business reality is when a feature is added, there's almost no way to remove it,
Even code-wise. Once a framework is adopted, it is hard to rip it out to make things lean again without making a fundamental change.