Software Principles¶

Each page below describes one principle you can use to guide your software engineering work.

Higher Judgment & Direction¶

Solve the Right Problem - Understand your customer and their needs. Define the right goals BEFORE you start designing.
What Ownership Is - Ownership is a competitive market. It can't just be mandated top-down.
If It's Not Written, It's Not Happening - In any significantly-sized company, effort not documented is unlikely to succeed.
The Problem with Deprecation - Large-scale deprecation rarely succeeds. Do some serious planning before announcing one.

Separate Concerns - No component should solve multiple sub-problems, and no sub-problem should be solved by multiple components.
Design Incrementally - Design for your current problem, break it down clearly, and design for incremental construction.
The Automation Spectrum - Automation is a ladder, you have to start at the bottom.
Leaf vs Root Problems - Distinguish between symptoms and causes. Fix the root to eliminate many leaves.
O(1) Effort per Change - As the number of already-supported functionalities increases, your cost to make changes should grow as little as possible.
If They Can, They Will - If the system permits an action, assume it will happen.
Boring is Good - Choose boring technology for critical infrastructure.
Do Not Repeat Yourself - Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
Modular Design - The most important tool for managing software complexity is the module.
Minimize Dependencies - Dependencies are liabilities, not free functionality.

The Rule of Two - You can copy code once. When you need it a third time, you must refactor.
Tests Or It Isn't Done - A feature is not complete until you can prove it works and ensure it keeps working.
Isolate Tests - Tests should not depend on each other or the environment.