Engineering principles

How we write code at Intempt. These principles apply to every engineer and every pull request. They 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 object-oriented code maintainable and flexible.

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. Use the simple approach first. Optimize later, after measuring. You can't optimize what you haven't profiled.

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 intuitive and obvious. Components should behave as expected. If a function name says “get,” it shouldn't modify state. Surprise is a bug.