Engineering principles

How we write code at Intempt. These principles apply to every engineer and every pull request - whether you're writing it yourself or reviewing AI-generated code from Claude Code or Cursor. AI writes the first draft; you own the final quality. These sit alongside our broader Work Principles and Operational Principles.

💋 1. KISS

Keep It Simple. Methods should be 40-50 lines max and address one problem. Use simple constructions. If someone needs a manual to understand your code, it's too complex.

🏜️ 2. DRY

Don't Repeat Yourself. If code appears more than twice, move it to a separate function. Automate any manual process you find yourself repeating. Duplication is the root of maintenance nightmares.

🙅 3. YAGNI

You Aren't Gonna Need It. Don't implement functionality unless it's necessary right now. Implement essential features first. Speculative code rots faster than useful code.

📐 4. BDUF

Big Design Upfront. Design first, create a flow diagram, then implement. This helps uncover issues before you write a single line of code. Cheaper to fix a diagram than fix production.

🧱 5. SOLID

Five principles that keep code from turning into spaghetti. You know these. We actually follow them.

Single responsibility principle

A class should have one reason to change. One job, one owner. When a class does too much, every change risks breaking something unrelated.

Open/closed principle

Open for extension, closed for modification. Add new behavior without touching existing code. Use interfaces and abstractions to make this natural.

Liskov substitution principle

Subtypes must be substitutable for their base types. If your subclass breaks expectations set by the parent, your hierarchy is wrong.

Interface segregation principle

Don't force clients to depend on methods they don't use. Many small, specific interfaces beat one large general-purpose interface.

Dependency inversion principle

Depend on abstractions, not concretions. High-level modules shouldn't depend on low-level modules. Both should depend on abstractions.

🐌 6. Avoid premature optimization

Root of all evil, per Knuth. Ship the simple version. Profile it. Then optimize the part that's actually slow. You'll be wrong about which part it is.

📏 7. Measure twice and cut once

Plan and prepare thoroughly before taking action. Verify requirements. Develop blueprints. The cost of planning is always less than the cost of rework.

😲 8. Principle of least astonishment

Code should be boring in the best way. If a function says “get,” it shouldn't modify state. If a button says “save,” it shouldn't delete. Surprise is a bug.