30 Architectural Principles for Software Engineers

Author Srinath, a scientist, software architect, and Apache Axis2 co‑founder, shares thirty widely‑accepted architectural principles he distilled from extensive experience in distributed systems.

Principle 1: Keep it simple (KISS) – use the simplest solution possible.

Principle 2: YAGNI – do not implement features until they are truly needed.

Principle 3: Crawl, walk, run – deliver a working version first, then iteratively improve with short milestones (max two weeks).

Principle 4: Automate testing – treat automation as the primary way to ensure high‑quality, stable products.

Principle 5: Consider ROI – only build what is cost‑effective.

Principle 6: Know your users – balance work based on real user needs.

Principle 7: Design and test features to be as independent as possible.

Principle 8: Avoid unnecessary flashiness; focus on functionality that will actually be used.

Principle 9: Embrace MVP – release a minimal viable product, gather feedback, then iterate.

Principle 10: Implement as few features as possible; leave extension points instead of full implementations.

Principle 11: Defer work until it is required, unless it affects core processes.

Principle 12: Be willing to say no to customers and propose better solutions; remember Henry Ford’s insight about asking for faster horses.

Principle 13: Understand the full stack (hardware, OS, language) and minimise I/O calls.

Principle 14: Apply Amdahl’s law – limit shared mutable state, use concurrency only when necessary, and keep lock hold times short.

Principle 15: In non‑blocking, event‑driven architectures, never block threads with I/O.

Principle 16: Stateless systems are scalable and straightforward; avoid stateful designs.

Principle 17: Strive for exactly‑once message delivery; recognize its difficulty and aim for lightweight designs.

Principle 18: Make operations idempotent to simplify recovery and support at‑least‑once delivery.

Principle 19: Know the CAP theorem; distributed transactions are hard, prefer compensation mechanisms.

Principle 20: Distributed consistency does not scale well; keep node counts modest (e.g., ≤8).

Principle 21: Accept that latency and failures are inevitable in distributed systems.

Principle 22: Understand user goals and expertise; tailor interfaces accordingly.

Principle 23: The best product needs no manual.

Principle 24: When undecided, avoid exposing every choice as a configuration option to users.

Principle 25: Provide sensible default values for all configurations.

Principle 26: Poor configuration design causes confusion; always include example values.

Principle 27: Configuration values must be understandable and directly editable by users.

Principle 28: Reject unknown configuration inputs with clear errors.

Principle 29: New programming languages rarely simplify problems; avoid frequent language switches.

Principle 30: Complex drag‑and‑drop UIs are costly; only attempt them with large, dedicated teams.

In summary, architects should act as gardeners—pruning and guiding rather than dictating—using this principle list as a shared anchor for discussion and learning.