30 Essential Architecture Principles Every Engineer Should Follow

Srinath, a scientist, software architect, co‑founder of Apache Axis2 and member of the Apache Software Foundation, shares his 30 architecture principles, emphasizing that architects should act as guides rather than definers.

Principle 1: KISS (Keep it simple, stupid) – keep everything as simple as possible and use the simplest solution to solve problems.

Principle 2: YAGNI (You aren't gonna need it) – don’t implement unnecessary features; add them only when needed.

Principle 3: Crawl, walk, run – first ensure it works, then optimize, then make it great; iterate with two‑week milestones for each feature.

Principle 4: Automated testing is the only way to create stable, high‑quality products; aim to automate everything.

Principle 5: Always consider ROI – only do what is worthwhile.

Principle 6: Understand your users and balance what you need to do; don’t spend months building a devops UI if users prefer a CLI.

Principle 7: Design and test a feature to be as independent as possible; independence simplifies releases.

Principle 8: Avoid flashy, over‑engineered features that are unlikely to be used.

Principle 9: Embrace MVP (Minimal Viable Product) – build a minimal version, release, then iterate based on feedback.

Principle 10: Do as little as possible; when in doubt, omit or remove features, leaving only extension points.

Principle 11: Wait for a request before implementing a feature unless it affects core flow.

Principle 12: Sometimes you must say no to customers and find a better solution; remember Henry Ford’s quote about a faster horse.

Principle 13: Know how a server works from hardware to OS to language; optimizing I/O calls is essential.

Principle 14: Understand Amdahl’s law; avoid shared mutable data and use concurrency primitives only when necessary, holding locks for minimal time.

Principle 15: In a non‑blocking, event‑driven architecture, never block threads or perform I/O in them.

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

Principle 17: Strive for exactly‑once message delivery, which is hard and often requires simplification.

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

Principle 19: Know the CAP theorem; distributed transactions are difficult, use compensation when possible, and remember RDBMS transactions don’t scale.

Principle 20: Distributed consistency does not scale; reliable cluster communication is limited, ideally to eight nodes.

Principle 21: In distributed systems you cannot avoid latency and failures; design for failure and consider SLA requirements.

Principle 22: Understand your users, their goals, and expertise level; geeks like extensibility, developers like examples, regular users like UI.

Principle 23: The best product needs no manual.

Principle 24: When you cannot decide between two options, don’t expose the choice as a configuration; provide a sensible default or automatic selection.

Principle 25: Always provide a reasonable default for configurations.

Principle 26: Poorly designed configuration causes trouble; always provide example values.

Principle 27: Configuration values must be understandable and directly settable (e.g., ask for max memory instead of max cache entries).

Principle 28: Throw an error for unknown configuration values; never silently ignore them.

Principle 29: New programming languages rarely simplify things; don’t switch languages lightly.

Principle 30: Complex drag‑and‑drop interfaces are hard; avoid unless you have a large team.

In summary, an architect should act like a gardener—pruning, guiding, and discussing rather than dictating—using this widely accepted principle list as an anchor for discussion and a learning path for junior architects.