The Skill of Removing Things

Every feature I've ever built started as a good idea. A real problem someone had, a reasonable solution to it, a clear path to implementation. And yet some of the best work I've done has been deleting features that were, by every rational measure, useful.

Why Removal Is Hard

Adding something to a product is additive in every sense. More functionality, more flexibility, more things to put on the marketing page. It feels productive. It feels like progress.

Removing something is the opposite. It feels like regression. Like admitting you were wrong. Like taking something away from people who might be using it. Even when the data shows that almost nobody uses it, there's a gravitational pull toward keeping things. "What if someone needs it?" "It's already built, what's the harm?"

The harm is subtle and cumulative. Every feature you keep is a feature you maintain. Every option in a menu is cognitive load for the person scanning it. Every configuration toggle is a path through your code that needs to keep working, needs to be tested, needs to be considered when you build the next thing.

Software doesn't collapse under the weight of one unnecessary feature. It gets slow, confusing, and fragile under the weight of fifty of them.

What I Look For

I've started paying attention to a few signals that tell me something should probably go.

Features people use but don't need. There's a difference. If your app has a built-in calculator and people occasionally use it, that doesn't mean it should exist. It means people will use whatever you put in front of them. The question isn't "do people use this?" It's "would people miss this if it were gone?"

Options that exist because you couldn't decide. A lot of settings pages are the graveyard of decisions the team didn't want to make. "Should the sidebar be on the left or right?" Instead of picking one, you add a toggle. Now you have two layouts to maintain, two sets of spacing to get right, two paths that can break independently. Just pick one.

Complexity disguised as flexibility. "But what if someone wants to..." is the most dangerous sentence in product development. Flexibility sounds good in theory. In practice, it means every user has to navigate a maze of options to get to the simple thing they actually wanted.

The Process

When I'm looking at something I've built and it feels cluttered or heavy, I ask: what would I remove if I had to remove one thing?

Not "what could I remove" - that framing invites you to say "nothing." But "what would I remove if I had to" forces a real evaluation. And almost always, there's an answer. There's a section that's pulling less weight than everything around it. An interaction that adds friction without proportional value. A visual element that's decorating rather than communicating.

Then I remove it and see what happens. Not hypothetically. Actually remove it, look at the result, and sit with it for a day. More often than not, the thing I removed isn't missed. The remaining elements breathe. The focus sharpens. The whole thing feels more intentional.

Simplicity Is a Result

I don't think simplicity is a starting point. It's what you arrive at after you've built too much and then carefully, deliberately cut back. The first draft of anything is going to be too complex because you haven't yet learned what matters.

The best interfaces, the best codebases, the best products - they all look simple from the outside. But that simplicity wasn't the first thing the team did. It was the last. After building, testing, observing, and then removing everything that didn't justify its existence.

Antoine de Saint-Exupéry put it better than anyone: "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."

In Code, Too

This isn't just about product design. It applies to code in the same way.

That utility function you wrote "in case you need it later" - you probably won't. That abstraction layer that handles three cases when you only have one - it's not simplifying your code, it's complicating it for a future that may never arrive.

I try to write code for the problem I have right now, not the problem I might have in six months. If the future problem shows up, I'll refactor then, with the benefit of actually understanding what the real requirements are. Speculative abstractions are almost always wrong because they're based on imagined constraints instead of real ones.

The hardest skill in engineering isn't making things work. It's knowing what not to build.