30 Architectural Principles for Software Engineers

Basic Principles

Principle 1: Keep it simple (KISS). Principle 2: You Aren’t Gonna Need It (YAGNI). Principle 3: Iterate – crawl, walk, run. Principle 4: Automate testing for stability. Principle 5: Consider ROI. Principle 6: Understand users and balance effort. Principle 7: Design and test features independently. Principle 8: Avoid unnecessary flashy features. Principle 9: Embrace MVP and iterate based on feedback. Principle 10: Minimize features; keep extensibility points.

Feature Selection

Principle 11: Build only when needed (unless core). Principle 12: Say no to customers when a better solution exists, guiding them like Henry Ford’s insight.

Server Design and Concurrency

Principle 13: Understand the full stack from hardware to language; optimize I/O calls. Principle 14: Apply Amdahl’s law; use concurrency only when necessary and keep lock hold time minimal. Principle 15: In non‑blocking, event‑driven architectures, avoid blocking threads or I/O.

Distributed Systems

Principle 16: Favor stateless, scalable designs. Principle 17: Strive for exactly‑once delivery, though it’s hard. Principle 18: Make operations idempotent to aid recovery. Principle 19: Know CAP theory; prefer compensation over distributed transactions. Principle 20: Distributed consistency does not scale beyond a small node count. Principle 21: Latency and failures are inevitable.

User Experience

Principle 22: Know your users, their expertise, and goals. Principle 23: The best product needs no manual. Principle 24: Avoid exposing complex configuration choices to users; provide sensible defaults. Principle 25: Always set reasonable default values. Principle 26: Provide example values for configurations. Principle 27: Configuration values must be understandable and directly settable. Principle 28: Reject unknown configuration values with errors.

Difficult Problems

Principle 29: New languages rarely simplify development; avoid frequent language switches. Principle 30: Complex drag‑and‑drop UIs are costly and should be avoided unless you have a large team.

Conclusion

The author likens an architect to a gardener—pruning, guiding, and discussing rather than dictating—emphasizing that a well‑accepted principle list helps teams avoid vague architectural debates and supports the growth of novice architects.