A few years back, I spent a fair amount of time exploring the Buddhist religion.
Though I don't practice Buddhism today, from time to time I like to listen to talks by some of the monks I came across while I was learning more about the religion.
My favorite is Ajahn Brahm. He's a monk based in Western Australia—full of wisdom, and happy as can be.
In his book Don't Worry, Be Grumpy he tells a story about a Buddhist nun who lives in a cave (a common practice for monks and nuns). In the cave, she kept an extra robe and one day comes back to notice that a mouse had chewed some holes in it. She stitched it up, only to come back a few days later and find more holes.
To solve the problem, she decides to get a cat to chase away the mouse. Then she finds that the cat needs milk every day. For a little while she gets the milk from some nearby villagers but after awhile realized she could just get a cow and milk it herself.
This goes on and on up to the point where the nun has hired a boy to tend to the cow and built a hut for him to live in.
When a villager did come to ask her some questions on meditation, she said, "Sorry. Not now. I'm too busy. I have to check the hut being built for the boy who looks after my field to graze my cow that provides the milk for my brown cat that keeps away the mice so that I don't need to keep patching my robe."
The point? It's easy to keep adding more stuff to solve a problem, but eventually, you're doing far more work than you would have implementing a simple fix.
When it comes to software products, this is all too common.
Again and again, we spend time creating problems for ourselves because we think that we need to take a more complicated path than we actually do.
We convince ourselves that we need to use a new convoluted library or framework to do something that we can do with what we already have.
We spend countless hours trying to implement a fancy animation that works across all devices when a simple one will do just fine.
We commit to a design for a feature, only to run into problems with it, and instead of scrapping it add workarounds until the point we're staring at a bowl of spaghetti.
It's too complicated
A lot of products fail because of problems just like these. It's not that the original idea wasn't good—it's that the implementation of it has become so convoluted, it's lost its purpose. Instead of retreating and admitting we've made a mistake, though, often we entrench ourselves.
In psychology circles, this is known as the sunk cost effect.
Be willing to go backwards to go forwards
From time to time, it's worth admitting defeat. When you're building your product, this is important to understand because it can mean the difference between long-term success and failure.
A recent example: I made some changes to the dashboard we use with mentees at Clever Beagle.
I though the changes were brilliant.
But, once it went live, I would watch people use it and immediately see confusion. They didn't know where to go or how to find what they were after.
What did I do? I redid it. I scrapped what I had, simplified it, and tried again.
What's important here isn't the change I made, but the willingness to admit I was wrong and make the change in the first place.
This is key: in order to truly embrace simplicity, you have to be willing to admit that you made something too complex to begin with and start again.
Skip complex UI just because "it looks cool"
The number one mistake I see mentees make—and I made myself when I was starting out—is convincing yourself that you need to implement a fancy, complex UI.
Well, you don't.
Back in 2013 when I was working on my first product, a friend who'd been building his own product for a few years met up with me over coffee so I could show him my progress.
His feedback: "why don't you just use Bootstrap?"
I was taken aback. Bootstrap?! How dare you suggest that I replace my beautiful, custom, unique UI with Bootstrap.
He was right. When I think back to that time, the idea itself wasn't terribly complex (an app for creating freelance contracts). At its core, it was a CRUD (create, read, update, delete) app.
Even with my limited skill set, what took me ~5 months to build could have been done in 2 months had I simplified my UI choices.
"No" now, "yes" later
This was one of the best things I've ever learned building products: just because you're choosing not to do it now doesn't mean you can't do it later.
When it comes to complex UI, skip it for your first version and save it for later.
Once you've had the opportunity to evaluate the feature and see if customers actually use it (and how they use it), then you can double-down and invest in something fancier.
Any time invested in a complex UI before you're certain it's what your customers need? It's just hubris and time wasting.
Avoid making features do more than one thing
Another bit of complexity that's easy to add but hard to catch yourself doing is trying to make a feature do more than one thing.
A common phrase I hear from mentees is "it has to do this, and this, and this."
Though it does tend to frustrate some folks, I say that because that's exactly what I ask myself when I'm working on my own products like Hound.
Check out Hound
A lot of what's discussed here can be prevented by visualizing what you're working on. I'm working on an app called Hound to help you do just that! Sign up here to get early access.
The truth is that most of what we think a customer needs is incorrect. It's important to understand that every time you implement a new feature, you're placing a bet.
What you're betting is that what you're implementing and how you're implementing it is correct. The more you invest up front, the more it's going to hurt when it doesn't work out as planned.
Typically, this is where most folks get discouraged. A big bet doesn't play out as expected and it casts a shadow over the entire project. When you intentionally bet small by saying "let me implement a simple version of this now and update it based on user feedback," you reduce the chances for killing your momentum.
As a bonus, the time you save not chasing complexity up front is time that you can spend honing the details on what already exists and ensuring it works to perfection.
If you can't answer why exactly something needs to exist, there's a good chance that you should leave it out or put it on the back burner for later.
The golden rule: quality over quantity
The overarching theme here is: less is more.
As you work on your product, always keep this in mind. The best thing to focus on is implementing less stuff of a higher quality.
The simpler everything is, the easier it is to perfect and the less time you will have to waste chasing bugs later. The fun part? All of that time saved now can be spent on implementing new—or improving existing—features later.