Learning · Software Engineering Manifesto
Prefer simple over clever
Clarity beats premature abstraction — complexity must pay rent in real requirements.
Principle
Every layer of indirection taxes every future reader and incident. Add complexity when a real requirement for scale, isolation, or change-rate demands it — not for resume-driven architecture.
Therefore we practice
- Start with the simplest design that meets known needs and operability bar
- Introduce distribution (more services, more brokers) only with a clear benefit and owner
- Prefer boring patterns the team can operate at 3 a.m.
- Delete unused abstractions; refuse speculative frameworks “for later”
- Document tradeoffs when you choose the complex path
Smells
- Microservices for a three-person app with one deploy per quarter
- Generics/frameworks nobody can debug
- Event choreography for a workflow that needed a single transaction
- “Future-proof” code that slows every present change