On the Power of Simplicity

May 2025

I've noticed something peculiar about how we solve problems in the technology industry. We have a tendency to add complexity when simplicity would serve us better. This pattern repeats itself across product development, design, and engineering.

I have an excellent prof in Mathew Campisi who teaches RTES at NYU. In the very first class, he mentioned how a defense project he was tasked with failed because of over engineering. You have a problem, your aim is to reach the minimum viable product in the least number of steps possible, fail if you have to, but reduce the steps and deliver value to the customer.

The instinct to add rather than subtract seems to be deeply ingrained in how we think. When faced with a problem, our first impulse is often to build something new—add a feature, create a process, or introduce a tool. Rarely do we consider what we might remove to make things better.

This additive bias manifests in products bloated with features that few use, in codebases riddled with unnecessary abstractions, and in designs cluttered with elements that distract rather than clarify. We've been conditioned to equate more with better.

But the most elegant solutions are often subtractive. Consider the evolution of the smartphone interface. Early mobile operating systems attempted to miniaturize the desktop experience, cramming tiny icons and complex menus onto small screens. It wasn't until designers embraced the constraints of mobile—removing elements rather than adding them—that truly usable interfaces emerged.

Or look at successful consumer products. The ones that achieve mass adoption tend to do one thing exceptionally well, rather than many things adequately. They remove friction and cognitive load instead of adding capabilities.

I've found this principle applies equally well to writing code. My best technical work has come not from adding clever algorithms or intricate patterns, but from removing unnecessary complexity. As programmers, we often measure our contributions by lines of code written. Perhaps we should measure them by lines of code deleted instead.

The barrier to embracing simplicity isn't technical—it's psychological. It requires overcoming the bias that equates effort with addition. It demands the confidence to recognize what's essential and the courage to discard what isn't. And perhaps most challenging, it requires resisting the temptation to demonstrate our value through visible complexity.

In a culture that celebrates building and creating, there's something counterintuitive about improvement through removal. Yet the most profound innovations often come from taking things away: removing friction from commerce, eliminating steps from a process, or stripping away layers between people and what they want to accomplish.

I've begun to apply this lens to my own work, asking not "what can I add to make this better?" but "what can I remove?" The results have been surprising. Projects move faster. Users understand products more intuitively. Code becomes more maintainable.

Simplicity isn't simple. It requires deliberate effort to achieve and constant vigilance to maintain. But the payoff—in clarity, usability, and impact—makes it worth pursuing.