Hacker News Reader

Comment by Ididntdothis | Hacker News Reader

I apply the scream test when refactoring. Comment out a feature and wait until someone complains. After half a year or a year start removing things. Works pretty well. This works better with internal systems. I wouldn't do it with external customers or at least only with a lot of thought.

View on HN

When using this technique, don't forget to account for infrequent processes - quarterly/annual reviews/audits, for example.

I go through a regular cycle of this at work. Hit a quarter end, encounter some weird thing which only happens at quarter end, add a special case to handle it, a month later, forget about it, delete it, hit another quarter end ...

Obviously.

You may end up unable to remove features that are now only used because they provide a workaround to the damage you did earlier.

This may still be a win if the removed feature was one that made future changes difficult. The code bade I spend a lot of time working on has some old/weird features that it seems exist only to be tested but nobody is using them.

But when asking the users you rarely get told to go ahead with removal.

This is a false dichotomy. If you're unsure of usage you could just instrument your code to log method calls and use that analysis to inform what maybe should be removed, but only if you first understand why.

This is client software. I am not getting any logs.

Once somebody screams, you can dig why and fix the underlying problem.

I imagine that none of the people criticizing the idea worked for long on any large organization.

> I imagine that none of the people criticizing the idea worked for long on any large organization.

Or what they worked on was too important for this risk to be taken. In my case, people could have literally screamed.

Yes, if it's really important, you don't remove it without a lot of digging. That's the the OP posted two contradictory principles.

This is perhaps the worst idea I've ever heard.

Reply on news.ycombinator.com