It doesn’t matter if it’s the first day of your career or you just had your 30th work anniversary. As a software engineer, you will subconsciously do one thing your entire life: overthink. You will design the most intricate and elaborate systems in your head when all you needed was a boolean value.

We can’t help it — it’s how we’re wired. It comes naturally to us. And honestly, there’s nothing wrong with exercising your brain a little bit. But it’s how far we take it that causes us problems.

Software takes careful design to build something truly powerful. What it does not take is weeks and weeks of meticulous planning to accommodate for all the edge cases. We used to do that, and we called it waterfall development. But we don’t do that anymore. We are agile.

The scary thing about overthinking your solution is how easy it is to do it. What seems like a straightforward path will quickly lead you down a rabbit hole. That rabbit hole will lead you to another, and another, and another.

Soon, you’ve reached the conclusion that you’re facing an impossible task. You might as well scrap the whole thing because you’ll never build the perfect software in any decent amount of time.

Well, you’re right about one thing: There is no such thing as perfect software.

Let’s discuss some strategies to help catch yourself when you start overthinking your solution.

Photo by Mia Baker on Unsplash.

Design for the 80%

Live by the 80/20 rule. Know that the primary use case of your application is going to be run 80% of the time. Combine all of the other edge cases and what-if scenarios, and you get the remaining 20%.

If you start thinking about use cases that don’t fall into the 80%, just stop. Write them down so you don’t forget them, then drop them. Your initial design does not need to cover every possible use case. What it does need to do is satisfy the business problem.

You’ll eventually come back to solve these use cases, but they’re not a problem for now. You’ll end up solving these problems one at a time instead of all at once.

Image by Giovanna Orlando from Pixabay.

Plan for Iteration

If you follow my writing, you know that I mention iteration at least once every article. That’s because it’s so important it’s worth repeating. You won’t build the best possible software on the first try. You need to build, get feedback, adjust, repeat.

The simplest and quickest method for building high-quality software is to iterate. Build small, incremental changes over time that enhance the experience. Think about building a house: It’s assembled brick by brick.

So when you start designing your software, don’t design your endgame. It’s not going to end up the way you first envisioned it. It’s going to evolve with feedback and grow into something you never anticipated.

It’s important to have a vision and keep that vision in mind, but remember that your journey is going to be far from what you expect it to be.

Photo by Glenn Carstens-Peters on Unsplash.

Hardcode What You Can

Configuration is a sneaky devil. A developer naturally wants to make an app configurable in as many areas as possible so it satisfies the maximum amount of use cases. But guess what? You don’t need to do that.

Don’t create complexity until it’s needed.

What problem are you solving by making it configurable? Has anybody asked for that? Probably not. Just hardcode it until you have a need. You’ll be surprised by how often your end users don’t ask for configuration.

Most people are heavily influenced by what they’ve seen before. If your company has a legacy application, watch out. Developers are going to suggest overcomplicated solutions because that’s how the legacy app does it.

Come up with a better solution! Don’t do something because it’s easy. Do it because it’s right.

Follow the 30-Second Rule

Have you ever heard of the term “elevator pitch”? It’s an expression used to describe the ability to explain an idea in the amount of time you’d spend with a person in an elevator.

Try to follow this rule when designing your applications. If it takes you more than 30 seconds to explain how it works, it’s likely too complicated or over-planned. You want a concise, easy-to-follow explanation that describes your idea.

A good architect makes a complex solution out of a complex problem. A great architect makes a simple solution out of a complex problem. Your goal is to be great. Focus on keeping your design simple and always aim to keep your explanation under 30 seconds.

Ask Yourself These Questions

Next time you are about to propose a solution, take a second and ask yourself the following questions to make sure you aren’t overthinking it:

1. Does my solution make sense?
2. Is there an easier way to solve the problem?
3. Could I explain this to a non-technical person?
4. Does the client really need this?
5. Can I easily iterate on this plan?

Sometimes, a simple checklist is all you need to help you stay on track and develop an easier solution.

The world has enough spaghetti code and over-architected solutions. It’s time we get back down to basics and make strong, iterable designs that delight the customer. Focus on simplicity. Your boss, coworkers, customers, and maintenance team will thank you.