Imagine you’re in a deli ordering a sandwich. You’ve decided what kind of cheese (swiss) and what kind of bread (focaccia) you want and now you’re looking at the possible meats you can put on it. Your eyes scan over all the big humps of smoked turkey, pastrami, roast beef … until you notice one weird one and wonder what the hell it’s doing there.

It’s a jalapeno peanut butter glazed ham.

You think to yourself: this thing takes up space in the fridge, has to be ordered and moved from a truck into shop, sorted and manually organized into a spot on the display, and then occasionally spoils and has to be replaced. All of this effort … for a couple of eccentric customers who occasionally order it? Even if it’s not a money-losing ham it’s definitely sucking up a lot of effort.

That weird ham is the equivalent of rarely used features in your product. It’s that obscure checkbox on the third tab of a config panel.

When presented with a feature request, you should fight the kneejerk response of: “Sure, why not. Just add it as an option. Another checkbox.”

Careless moves like that are the slow road to disaster.

That new option has all these characteristics:

It adds another code path and another corner case. Because that code path is exercised by 1% of users, it’ll break one day but you’ll only find out many weeks later.
It is less testable (or requires a special new test to be written) When something changes, the special test may break and need to be rewritten.

It incurs mental and communication overhead across the team. Other engineers need to be constantly aware of it to avoid accidentally introducing a side effect somewhere else that breaks it. Folks making documentation need to update screenshots and write about it. All folks in your Support department need to be made aware of it and deal with inquiries about it.

It clutters your UI with an element that is visually distracting to everyone who doesn’t care for it. Depending on what it is, it may even give your users more opportunity to screw up. Furthermore, your designers will have to struggle with this wart forever.
It represents exponential complexity. This is actually the most important negative effect that will cripple you over time, and the one you must be most vigilant against, because it kills you by thousands of small bites.
The complexity of your system is NOT expressed as O(lines of code). It’s actually roughly O(2^number of checkboxes). Don’t dismiss it as “just another checkbox” and “just” a quick ten-line fix. That seemingly innocuous feature has effectively doubled the complexity. The deeper it is, the worse the compounding effect.

I'm not saying don't add options; after all, flexible and powerful software is incredibly valuable. There are ways to contain them. Value them carefully and just remember that if left to proliferate unchecked, they can become like an invisible anchor dragging behind your boat. They weigh a hell of a lot more than the twenty pixels you can see.

Given finite resources, this deadweight will impact all other factors of your company: how fast you can put out new product, its reliability and quality, the level of service you provide, and the price of your service ... the sum total of which equals the scale of the impact you can have.