How to Know If your Software Is Overcomplicated or Oversimplified?

Dec 19, 2025

Explore the fine line between overcomplication and oversimplification in software. Discover how unnecessary patterns from conferences can create accidental complexity. Learn the difference between essential and accidental complexity, and why simplistic advice can often be misleading. Hear insights on matching patterns to domain needs and the importance of incremental changes. The discussion also highlights red flags for unhealthy projects, emphasizing the need for a balanced approach to software architecture.

Ask episode

AI Snips

Chapters

Transcript

Episode notes

INSIGHT

Essential vs Accidental Complexity

Essential complexity comes from the domain and cannot be removed by engineering choices.
Accidental complexity is created by poor implementation and unnecessary patterns.

ANECDOTE

Ivory Tower Patterns Harm Projects

Robert describes joining projects where senior engineers enforce patterns seen at conferences.
Those patterns add unnecessary complexity because the person often lacks deep understanding.

ANECDOTE

Prototype Turned Tightly Coupled Product

Milos recalls projects that started as single-file prototypes that later became hard to change.
The codebase became tightly coupled and resisted extensions as the product grew.

Get the Snipd Podcast app to discover more snips from this episode

Get the app

Episode notes: https://threedots.tech/episode/overcomplicated-vs-oversimplified-code/

Quick takeaways

Complexity comes from two extremes - projects fail both when they’re overcomplicated with unnecessary patterns and when they’re oversimplified for a complex domain
Essential vs accidental complexity - essential complexity comes from the domain itself and can’t be removed, accidental complexity is created by poor implementation choices
“Keep it simple” is lazy advice - achieving simplicity takes effort; closing your eyes to complexity just pushes it elsewhere
Match patterns to the problem - using the same approach everywhere is a red flag; mix simple solutions for simple parts and sophisticated patterns for complex domains
Ship fast and iterate - if you can’t deploy daily and fear making changes, something is wrong regardless of whether it’s over or under-engineered

We discuss where complexity in software projects comes from and how to deal with it. There are two common extremes: projects that are overcomplicated because someone applied patterns they saw at a conference without understanding them deeply, and projects that started simple but became a tangled mess as they grew.

Both can be equally difficult to work with. The key insight is understanding the difference between essential complexity (inherent to your domain) and accidental complexity (created by your implementation choices). We share diagnostic signals to identify unhealthy projects and practical advice on matching your tools to the actual problem you’re solving.

No Silver Bullet paper by Fred Brooks - discusses essential vs accidental complexity
Domain-Driven Design (DDD) - a pattern for tackling complex domains
Clean Architecture - another approach for managing complexity
YAGNI (You Aren’t Gonna Need It) - principle against premature generalization
Defensive programming - validating inputs early to prevent errors propagating
Canary releases and rollbacks - deployment strategies that can add overhead
Three Dots Labs blog - articles on Go patterns and architecture
Go with the Domain ebook - free ebook about DDD in Go with 60,000+ downloads
Wild Workouts example DDD project - complex Go project demonstrating real-world patterns
Microservices architecture - discussed as sometimes adding unnecessary complexity
CRUD applications - simple approach that works for some domains but not others
The Domain Engineer training - upcoming training mentioned for early next year