The Complexity Industrial Complex
Who Profits From Overengineering?
Full disclosure: This post was written by a human (me), polished by an AI (it fixed my grammar and made me sound smarter), then reviewed by me again (to make sure the AI didn't make me sound too smart). Any remaining errors are 100% organic, artisanal, human-made mistakes.
DHH used the term "merchants of complexity" to describe an uncomfortable truth: there's an entire industry that profits when software is complicated. Consultants, tool vendors, cloud providers, and even developers themselves have incentives to add complexity—whether or not it serves the product.
Who Benefits From Complexity?
1. Consultants and Agencies
Complex architectures require experts to implement and maintain. A simple monolith needs a small team. A microservices architecture needs specialists, training, and ongoing support. Which engagement is more profitable?
The consulting model: Recommend complex solution → Client can't implement alone → Client needs ongoing consulting → Repeat
2. Tool and Platform Vendors
Kubernetes, service meshes, observability platforms, API gateways—these solve real problems that complexity creates. But they also have sales teams incentivized to expand complexity to expand their market.
3. Cloud Providers
AWS offers 200+ services because each service is revenue. A complex architecture using 15 services generates more billing than a simple one using 3. The "well-architected framework" often means "uses more services."
4. Developers Themselves
This is the uncomfortable part. Developers benefit from complexity:
- • Complex projects look more impressive on resumes
- • Complex systems require more developers (job security)
- • Learning complex tools signals expertise
- • Complex solutions feel more "engineering" than simple ones
The Career Incentives Problem
"Nobody ever got promoted for saying 'we don't need that.' The incentives are always to add more—more services, more tools, more architecture. Simplifying looks like you're not doing anything."
— DHH on complexity incentives
Consider two developers proposing solutions:
Developer A:
"We should add the feature to our existing Rails app. It'll take a week, and we don't need any new infrastructure."
Sounds like they're not doing much...
Developer B:
"We should build a new microservice with its own database, add Kafka for event streaming, and use Kubernetes for orchestration. It'll take a quarter."
Now THAT'S engineering!
Developer B's proposal is more visible, more promotable, and more resume-worthy. Even if Developer A's solution is better for the business, the incentives reward B.
How Complexity Gets Sold
The "Scale" Argument
"We need to build for scale!" But do you? Most companies will never hit scale problems. And if you do, congratulations—you have users and revenue. You can solve it then with actual data.
The "Future-Proofing" Argument
"We might need this flexibility later!" Maybe. But you're paying the cost now for a benefit that may never materialize. YAGNI (You Aren't Gonna Need It) exists because most future-proofing is wasted.
The "Best Practices" Argument
"Everyone's doing microservices!" Best practices from Google, Netflix, and Amazon exist to solve their problems at their scale. You are not Google. Your "best practice" might be dramatically different.
The "Resume-Driven" Argument
"Let's use Kubernetes—I want to learn it." At least this is honest. But optimizing your company's architecture for your resume is a conflict of interest.
The Real Cost of Complexity
Complexity isn't free. It compounds:
The Complexity Tax
- • Hiring: You need specialists who understand your complex stack
- • Onboarding: New developers take months to understand the system
- • Debugging: Issues span multiple services and require archaeology
- • Deployment: Changes require coordinating multiple deployments
- • Testing: Integration testing becomes exponentially harder
- • Operations: More services = more things that can fail
- • Cost: Infrastructure, tooling, and personnel all scale up
A team that could ship features weekly with a monolith might ship monthly with microservices. The complexity overhead doesn't just add cost—it reduces output.
Resisting the Pressure
1. Follow the Money
When someone recommends complexity, ask: who benefits? Consultants, vendors, and platform providers have financial incentives. Internal developers have career incentives. Acknowledge these and discount accordingly.
2. Demand Proof of Need
Before adding complexity, require evidence that it's needed. Not hypothetical future need—actual current need. Load test your monolith before declaring it can't scale.
3. Calculate Total Cost of Ownership
Don't just count implementation time. Count ongoing maintenance, operations, debugging, and the cognitive overhead of understanding the system. Simple solutions often win on total cost.
4. Reward Simplification
Change the incentives. Celebrate engineers who remove code, simplify architecture, and reduce dependencies. Make "we don't need that" a promotable achievement.
5. Question "Best Practices"
Every best practice has a context. Netflix's architecture makes sense for Netflix. Ask: does this make sense for us, at our scale, with our team, solving our problems?
Simplicity as Competitive Advantage
Here's the counterintuitive truth: simplicity is a competitive advantage precisely because the industry pressures toward complexity. While your competitors are wrestling with their microservices architecture, you're shipping features.
The Simplicity Advantage
- • Speed: Ship features faster with less coordination
- • Quality: Less complexity = fewer bugs and failure modes
- • Cost: Less infrastructure, fewer specialists needed
- • Agility: Simple systems are easier to change
- • Resilience: Fewer moving parts = fewer things to fail
Basecamp, Hey, GitHub (before Microsoft), and countless profitable companies run on simple architectures. They win not despite simplicity but because of it.
Fighting the Good Fight
The complexity industrial complex isn't a conspiracy—it's an emergent property of incentives. Consultants, vendors, and developers all do what they're rewarded for. Changing the outcome requires changing the incentives.
Every time you choose a simple solution over a complex one, you're fighting the good fight. Every time you say "we don't need that," you're resisting the pressure. It's not glamorous, but it's valuable.
The greatest skill in software engineering might be saying "no" to complexity.
Not because simple is easy—simplicity is hard. But because every piece of unnecessary complexity is a tax you'll pay forever. The merchants of complexity won't stop selling. But you can stop buying.
Related Articles
Most Software Is Just CRUD (And That's Okay)
Create, Read, Update, Delete—the honest foundation most developers ignore. Why we over-complicate to avoid existential dread about mundane work, and how embracing simplicity is professional maturity.
Small Teams Beat Large Organizations (And Here's Why)
Basecamp's origin story and why 15 specialized roles at Facebook created unnecessary complexity. The economics of simplicity vs. the politics of headcount, and how to structure teams for actual output.
The Pieter Levels Model: One Developer, Simple Tools, Millions in Revenue
PHP, jQuery, SQLite powering million-dollar businesses. Why 'boring' technology wins, and what solo developer success stories teach us about the myth that you need modern frameworks to build real products.