Accidental Complexity

Unnecessary difficulty introduced through implementation choices, technology decisions, or misapplied patterns.

Accidental complexity is the difficulty you create by how you solve a problem, not by the problem itself.

The term comes from Fred Brooks' 1986 paper No Silver Bullet, where he distinguishes it from Essential Complexity. Essential complexity is inherent to the domain. Accidental complexity is something you introduce through your technology choices, abstractions, or architecture decisions.

Both overcomplicated and oversimplified code create accidental complexity. When you apply patterns you don't need (microservices for a simple CRUD app, a Saga where a local transaction would do), you're adding accidental complexity. But when you use trivial code for complex behavior, you're also adding it. The complexity doesn't disappear. It just moves into implicit rules, workarounds, and bugs that are harder to trace.

The goal isn't to eliminate all complexity. It's to make sure most of the complexity in your codebase is essential. Patterns like DDD, Clean Architecture, and proper domain modeling exist to reduce accidental complexity by giving you tools that match the shape of the problem.

If you can ship features daily and aren't afraid to make changes, your accidental complexity is probably under control. If every change feels risky and slow, it's worth asking how much of that difficulty is inherent to the domain and how much you've introduced yourself.