“Whenever you find yourself on the side of the majority, it is time to pause and reflect.” — Mark Twain

While listening to The Tim Ferriss Show, I heard a question that could be helpful for developers. The episode was about, Testing The “Impossible”: 17 Questions That Changed My Life.

Question number eleven was the one that seemed beneficial for teams making software.

#11 — What if I could only subtract to solve problems?

From 2008 to 2009, I began to ask myself, “What if I could only subtract to solve problems?” when advising startups. Instead of answering, “What should we do?” I tried first to hone in on answering, “What should we simplify?”

For instance, I always wanted to tighten the conversion fishing net (the percentage of visitors who sign up or buy) before driving a ton of traffic to one of my portfolio companies. One of the first dozen startups I worked with was named Gyminee. It was rebranded Daily Burn, and at the time, they didn’t have enough manpower to do a complete redesign of the site. Adding new elements would’ve been time-consuming, but removing them wasn’t. As a test, we eliminated roughly 70% of the “above the fold” clickable elements on their homepage, focusing on the single most valuable click. Conversions immediately improved 21.1%.

That quick-and-dirty test informed later decisions for much more expensive development. The founders, Andy Smith and Stephen Blankenship, made a lot of great decisions, and the company was acquired by IAC in 2010. I’ve since applied this “What if I could only subtract . . . ?” to my life in many areas, and I sometimes rephrase it as “What should I put on my not-to-do list?”

— Tim Ferriss, Tools of Titans

On most software teams I’ve worked on we’ve always focused on adding more features. My guts telling me that spending some time to remove features would also be beneficial.

Systems that are rarely used won’t lie dormant in the code base, reducing the amount of technical debt. This could even help you avoid zombie test cases.

This question could also help during the planning phases of development. Could a new outcome happen using only current code? Could quality improve by refactoring one area of the code base?

Sometimes we want to try and do more when we should be trying to do less.

What if you could only subtract to help solve your next software problem?