Development Best Practices¶
Status: 🟢 Active | Owner: Engineering Enablement | Last Reviewed: 2025-Q4
Introduction¶
Development best practices are the foundation of everything we build. They are the standards that apply regardless of which team you are on, which language you are writing in, which product you are building, or which cloud you are deploying to. They represent the accumulated engineering wisdom of the organisation — the lessons learned from production incidents, painful refactors, slow onboardings, and hard-won code reviews.
This section covers the practices that every software engineer at this organisation is expected to understand and apply. They are not optional suggestions. They are the baseline from which all other, more specific standards are derived.
Intent¶
The intent of this section is to establish a universal engineering baseline — a set of practices so fundamental that any engineer, on any team, in any language, should be applying them every day.
Consistency at Scale¶
As engineering organisations grow, inconsistency compounds. Two teams solving the same problem in incompatible ways create integration friction. Three different approaches to naming, four different testing strategies, and five different ways of handling errors mean that every cross-team collaboration starts with a translation exercise. Development best practices eliminate this translation layer by establishing shared conventions that apply everywhere.
Quality as a Default¶
The standards in this section are designed to make doing the right thing the path of least resistance. Linting configurations are checked in. Test coverage is enforced in CI. Documentation templates are provided. The goal is an environment where quality is not the result of heroic individual effort but the natural outcome of following the established workflow.
Enabling Confident Change¶
Well-written, well-tested, well-documented code can be changed with confidence. Poorly structured, untested, undocumented code becomes a liability that slows every future change and concentrates risk in the engineers who happen to know where the bodies are buried. The practices in this section exist to keep codebases in a state where any engineer can pick up any service and make changes safely.
What You Will Find Here¶
| Section | Intent |
|---|---|
| Coding Standards | Language-agnostic rules for writing readable, consistent, maintainable code |
| Software Design Principles | SOLID, DDD, design patterns, and anti-patterns to avoid |
| Architecture Patterns | Approved architectural styles and when to apply each |
| Source Control & Branching | Git conventions, branching strategy, PR standards, and code review |
| Testing Standards | Testing philosophy, coverage requirements, and approved testing patterns |
| Documentation Standards | ADRs, READMEs, API docs, runbooks, and diagrams-as-code |
| Dependency Management | Approval, pinning, licensing, and vulnerability scanning |
| Technical Debt Management | How to identify, classify, track, and pay down technical debt |
Relationship to Other Sections¶
Development best practices are intentionally language-agnostic and stack-agnostic. For language-specific implementation guidance, see Programming Languages. For the tooling that enforces these practices automatically, see Required Developer Tooling. For how these practices are verified in the delivery pipeline, see CI/CD & Delivery.
Last reviewed: 2025-Q4 | Owner: Engineering Enablement