The principle
Software is easier to run when there is less of it. Prefer boring, well-known technology, keep interfaces small, delete dead code and unused features, and release in small steps so each change is easy to reason about. Every part the problem can do without adds load for whoever is on call.
Source: Google's Simplicity. Stefan Coetzee's framework has no simplicity pillar of its own; the nearest is Idempotence as the IaC Invariant under Infrastructure as Code: the same input gives the same end state, which keeps a system easy to reason about.
On this platform
- Static files. The three sites are files on GitHub Pages. Readers depend on no server, database or application runtime that the operator runs (Site architecture).
- Standard library only. The generators are Python with no packages to install; the YAML for services and incidents is read by a strict subset reader in
scripts/mini_yaml.py(Service catalog). - No third-party requests on page load. Fonts are self-hosted, and no analytics or CDN script loads in a reader's browser. The map moved its d3 library and fonts from public CDNs into the repository (ADR-0010, superseding ADR-0003).
- One of each. One navigation source for the chrome of every page (ADR-0021), one gate for three sites, one workflow, one search index (ADR-0012).
- Data next to the code. Services and incidents are YAML files in the repository, read at build time; there is no database for the portal (ADR-0013, ADR-0014).
State
In place. The platform runs on few moving parts, and the decision records show where a part was removed. It carries three costs of its own: generated HTML committed next to its sources, four build commands that must run in order (Docs tree), and a bot commit on main after every gate run (#39).
Services that name it
In a company of 10 to 200 people
- Choose the managed or boring option by default, and write a decision record when you choose something new.
- Count the moving parts a customer request passes through, and remove one each quarter.
- Delete features nobody uses, with the same ceremony as shipping one.
- Keep one way to do each common thing: one pipeline, one service template, one place for docs.