How often have you worked on a project that was REQUIRED to and be “internet-scale”? over-engineer These projects bring a ton of assumptions – handling millions of users, hundreds of requests per second, and massive storage needs. It takes months to build these high-scale features. Delays will happen. Stakeholders get frustrated. And yet, your team gets it done. Unfortunately, the only user is Steve in Marketing. He needed to email a fancy report once a week. I’ve encountered this situation TOO MANY times in my career. Sometimes I caused the problem. Other times I had to talk people off a ledge. Over the years, I’ve learned that : the right time to over-engineer a project depends on one thing Understanding the problem you’re trying to solve. What problem are you ACTUALLY solving when you over-engineer? Engineers are enamored with the idea of “ “. We love building things and thinking about the future. Unfortunately, that excitement leads to problems from above. What’s possible? Thinking about “what’s possible?” adds scope. To get around this, you have to focus your energy. Don’t take the requirements for granted. Pay attention to the assumptions your team is making. Ask the critical question to your stakeholder: What outcome is the customer looking to achieve? But your curiosity should not end there. You need to understand the you’re working in. Look at how your broader company works. context What are the goals of the business this year? Does your company sell to small businesses or enterprises? What resources does your team have at its disposal? This information will show you the trade-offs you need to make and where to invest your time. So when exactly should you over-engineer a project? When should I ship a software project as fast as possible? I optimize for shipping a project as fast as possible when the goal is to learn. Start-ups are the best example of this. The early days of a start-up business prioritizes product-market fit. The goal is to find customers and learn quickly. It’s OK to write if it means you ship. just enough code We can always make the system more resilient later. So if your company is exploring a new domain, optimize for shipping over robust systems. When should I over-engineer my software project? I recommend over-engineering a project when it meets two requirements: The system is needed to achieve long-term business goals. You have a deep understanding of the problem space. Over-engineering is perfect for systems that are core to the business. These are old systems that are used by most customers and keep getting new features. Examples include Google Search, Facebook’s News Feed, or even the user permission settings in your web app. Each of these systems has had some sort of re-write over the years. While risky, their success is due to understanding the codebases and aligning a rewrite with the company’s long term goals. I’ve personally encountered this in my day job. Over the past six years, my team migrated our app to three different database technologies. Each migration was worth it until we hit a mixture of traffic scale and use cases that pushed the system to the limit. Each re-write was a success thanks to great planning, aligned goals, and . healthy project estimation Using Jobs to Be Done to know when to over-engineer a Project The is a great tool to evaluate when to over-engineer a project. This framework asks you to think about the specific job customers hire your product to perform. Jobs to Be Done framework My favorite example of this comes from Competing Against Luck when the author tries to answer the question: “Why do people by McDonalds milk shakes in the morning?” …what these milk shake buyers had in common had nothing to do with indvidual demographics. Rather, they all shared a common job they needed to get done in the morning. “Help me stay awake and occupied while I make my morning commute more fun.” Christensen, Clayton M., et al. . New York, N.Y. Harper Business, An Imprint Of Harpercollins Publishers, 2016. Competing against Luck the Story of Innovation and Customer Choice These people weren’t just buying milkshakes as desserts to their meal. They wanted something with high calories, easy to consume while driving, and quick to buy on their way to work. Understanding the specific outcomes your customer is trying to achieve will help you know when to over-engineer a project. When the outcome is to learn, forego quality and ship fast. But when the goal is to scale, then over-engineer the hell out of your software. How do you figure out when to over-engineer a project? Let me know on or . LinkedIn Twitter Further Reading Competing Against Luck by Clayton Christensen The Critical Path Episode 19 The Critical Path Episode 134 The Critical Path Episode 146 Want to learn how to become the successful leader your team needs? to learn how. Sign up for my newsletter

Apple

Facebook

Google

Twitter

Become the successful leader your team needs.

I only care about one thing.

Helping YOU become the successful leader you deserve to be.

2021 - HackerNoon Contributor of the Year - ENGINEERING-MANAGEMENT

2022 - All About Teamwork

2022 - HackerNoon Contributor of the Year - Engineering Management

2022 - HackerNoon Contributor of the Year - Hacking

2022 - HackerNoon Contributor of the Year - Management

2022 - HackerNoon Contributor of the Year - Management And Leadership

2022 - HackerNoon Contributor of the Year - Product Management

Tip a coffee and support Build the Stage

2021 - HackerNoon Contributor of the Year - TEAMWORK

Nominated for 2022 - All About Teamwork

Nominated for 2022 - HackerNoon Contributor of the Year - Engineering Management

Nominated for 2022 - HackerNoon Contributor of the Year - Hacking

Nominated for 2022 - HackerNoon Contributor of the Year - Management

Nominated for 2022 - HackerNoon Contributor of the Year - Project Management

Nominated for 2022 - HackerNoon Contributor of the Year - Management And Leadership

Too Long; Didn't Read

Developers: Build Less. Deliver More. [Learn how]	

When Over-Engineering Is A Good Idea

When Over-Engineering Is A Good Idea

Too Long; Didn't Read

Companies Mentioned

John

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

When Over-Engineering Is A Good Idea

Too Long; Didn't Read

Companies Mentioned

John

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES