Junior engineers add complexity. Senior engineers remove it.
This isn’t because senior engineers are smarter. It’s because they’ve learned, painfully, what complexity costs.
The Complexity Tax
Every piece of complexity in your product has a cost:
- Development cost: More code to write, more parts to design, more interactions to test
- Manufacturing cost: More assembly steps, more potential failure points, more inventory to manage
- Maintenance cost: More documentation to maintain, more tribal knowledge, more things that can break
- Opportunity cost: Time spent on complexity is time not spent on what matters
Complexity compounds. A system with 10 interacting components doesn’t have 10x the complexity of a single component — it has 100x.
Why We Add Complexity
Complexity feels productive. Adding a feature feels like progress. Adding a safety check feels responsible. Adding flexibility feels smart.
But every addition is a tradeoff. The question isn’t “does this add value?” — it’s “does this add more value than it costs?”
Common complexity traps:
“Just in case” features: Building for requirements you might have someday. You probably won’t. And if you do, your assumptions will be wrong anyway.
Premature abstraction: Making things flexible before you know what flexibility you need. Abstraction isn’t free — it adds indirection and cognitive load.
Defense in depth overkill: Yes, redundancy is good. But four layers of validation where one would do isn’t safety — it’s complexity.
The Discipline of Simplicity
Simple doesn’t mean easy. Getting to simple is hard work.
It requires:
Deep understanding: You can’t simplify what you don’t understand. Simple solutions come from deeply understanding the problem.
Courage: Simple solutions often feel too simple. They feel like you’re not doing enough. You are.
Iteration: The first solution is rarely the simplest. You have to be willing to throw things away and start over.
Saying no: The simplest way to keep something simple is to not add things to it.
The Test
Before adding anything, ask:
- What problem does this solve?
- Is this problem real or hypothetical?
- What’s the simplest thing that could solve it?
- What’s the cost of not solving it?
If you can’t answer these clearly, you probably shouldn’t add it.
Simple Scales
Here’s the thing about simple: it scales.
Simple products are easier to manufacture at volume. Simple codebases are easier to maintain and extend. Simple processes are easier to train people on.
When you’re small, complexity is manageable. When you scale, complexity kills.
Build simple from the start.
Expertise Engineering builds simple, robust hardware products. Let’s talk about what you’re building.