Technische Einfachheit prüfen

Engineering Simplicity Review

Use this skill when reviewing technical designs, implementation plans, or code diffs to ensure accidental complexity is removed before it becomes a permanent maintenance burden.

What Genuine Simplicity Means

• Lifecycle simplicity over line-count golf: A 40-line explicit module with clear types and error handling is simpler than a clever 8-line meta-programmed one-liner or a "quick hack" that requires weekly manual database fixes.
• Deep modules over shallow pass-through layers (Ousterhout): Every new class, interface, wrapper, or microservice must hide significant complexity behind a simpler interface. If an abstraction has the same surface area as the code it wraps, delete the wrapper.
• Non-negotiable foundations are part of simplicity: Authorization checks, tenant isolation, input validation, transactional integrity, and clear error handling are never "over-engineering" — they are required for a working system.

Checklist for Spotting Accidental Complexity

1. Premature generalization & single-implementation interfaces:
   • Flag IFooAdapter, AbstractFooFactory, or strategy registries created when only one concrete implementation exists and no second implementation is scheduled in the current scope.
   • Require at least three concrete call sites or two real domain variants before extracting a shared framework or configurable abstraction; mere syntactic similarity between two functions is not enough.
2. Pass-through layers & indirection:
   • Flag controllers, services, mappers, and DTOs that copy identical fields across 3–4 layers without transforming semantics or enforcing a boundary.
3. Unjustified new dependencies or infrastructure:
   • Before adding a third-party package, queue, cache cluster, or state-management library, verify whether standard language/runtime APIs or packages already in package.json / composer.json / pyproject.toml solve the problem.
   • Weigh total cost of ownership: bundle size, security patching, upgrade churn, and operational failure modes.
4. Full rewrites disguised as features:
   • Challenge proposals to rewrite a working module from scratch when a targeted, incremental change or strangler step achieves the goal with far lower regression risk.
5. Unmeasured performance complexity:
   • Reject complex caching layers, custom memory pools, or denormalized sync pipelines unless tied to a measured bottleneck or explicit capacity requirement.

Review Output Contract

Always pair every critique with a runnable, simpler alternative:

Goal: [The concrete requirement or user outcome] Observation: [The specific layer, dependency, or abstraction that exceeds what the goal requires, and the maintenance/failure cost it introduces] Proposal: [The concrete simpler design using existing codebase primitives, plus its known limits] Trade-off: [What we defer and the exact condition that would justify adding the extra layer later]