Hacker News Reader

Comment by gingerlime | Hacker News Reader

> and be ready to retire it and delete the code when it turns out to be useless

There lies the problem though. It's so much easier to add stuff, but so much harder to remove it. Because then you get shouted by the loudest 0.1% of your user base, who happen to use this useless feature. And nobody's going to fight for removing something. Well, not nearly as hard as people fight to add their brightest idea to the product.

View on HN

One technique i use is to accidentally break features i want to get rid of. Then when nobody complains, i can just delete the old broken feature that nobody uses anyway.

Ah, yes, the Google strategy. Accidentally break the feature, then look at the analytics six months later when nobody uses it because it doesn't work, decide that it was a useless feature, just remove it instead of fixing it.

And I mean, I'd lodge a formal complaint about the broken feature but I'm not even sure I can file a bug report with the specific Google service, and the last 10 complaints I managed to file all got bitbucketed anyway so why even bother.

So I'll just grumble and stop using your product, because you can't seem to write features that work.

That's an interesting idea, and is effectively a trial run of fully removing a feature. Though, does that imply that you're working in a codebase without automated testing? With automated testing, the "accidental" breakage would be more likely to be caught.

It tends to be that for features people mostly don't care about, the automated tests started failing years ago, and nobody will prioritize fixing them.

At some point there was automated tests, but their failures are now ignored or have been turned off.

Reply on news.ycombinator.com