The Modern SDLC Series: Everything We Covered — By the Numbers
The Modern SDLC Series: Everything We Covered — By the Numbers
A meta-post on The Modern SDLC series — your map to the full 18-post collection.
When I set out to write this series, the goal was simple: cover the entire modern software development lifecycle in a way that a senior engineer would actually find useful, not just a checklist of tools and buzzwords. One post per phase, no fluff, real opinions.
Eighteen posts later, here's what that actually produced — and a map to help you find the parts most useful to you.
The numbers
| Metric | Count |
|---|---|
| Posts in the series | 18 |
| Total words written | 49,053 |
| Average words per post | 2,788 |
| Total sections | 189 |
| Estimated reading time | ~3.5 hours |
| Unique tools and platforms covered | 82 |
| Distinct methodologies and frameworks | 26 |
| Failure modes and anti-patterns named | 32 |
| Actionable checklists | 8 |
| Checklist items across the series | 35 |
| Programming languages covered | 8 |
The reading time estimate uses a 230 words-per-minute reading pace — comfortable technical reading, not skimming. At that pace, the full series is roughly a long-haul flight's worth of material. Each individual post is 10–15 minutes.
The 82 tools covered
One of the stated goals of the series was to be specific rather than vague. "Use a good testing tool" is not useful advice. "Use Testcontainers with a real Postgres container for your integration tests, keyed on your lockfile hash in CI" is.
That specificity required naming real tools. Here's every tool covered across the 18 posts, organised by category.
CI/CD and pipelines GitHub Actions, GitLab CI, Buildkite, Dagger, Turborepo, Nx, Atlantis, Terraform Cloud, Argo Rollouts, ArgoCD, Flux, semantic-release, release-please
Containers and orchestration Docker, Kubernetes, Helm, Kustomize, Karpenter, KEDA, Cluster Autoscaler, Vertical Pod Autoscaler, Istio, Linkerd, Cilium, EKS, GKE, AKS
Infrastructure as Code Terraform, OpenTofu, Pulumi, Crossplane, Checkov, tfsec, Trivy, Infracost, Open Policy Agent (OPA), Kyverno
Observability Prometheus, Grafana, Grafana Tempo, Grafana Loki, Jaeger, OpenTelemetry, Datadog, Honeycomb, New Relic, OpenSearch, Elasticsearch, Splunk, OpenCost, Kubecost
Security Semgrep, CodeQL, Snyk, Gitleaks, Trufflehog, Bandit, OWASP Dependency-Check, Cosign, Sigstore, FOSSA, CycloneDX, Syft, HashiCorp Vault, AWS Secrets Manager, External Secrets Operator
Testing Testcontainers, Playwright, Cypress, Jest, pytest, pytest-xdist, fast-check, Hypothesis, Pact, k6, Gatling, axe-core
Developer toolchain Husky, pre-commit, lint-staged, commitlint, Renovate Bot, Dependabot, pnpm, uv, Poetry, asdf, mise, Prettier, Black, Ruff, ESLint, mypy, pyright
Incident and on-call PagerDuty, OpsGenie, Grafana OnCall, Alertmanager, Rootly, FireHydrant, Statuspage
Platform and developer experience Backstage, Port, Cortex, LinearB, Swarmia, Faros
Deployment targets Vercel, Netlify, Railway, Render, Fly.io, AWS App Runner
That's a lot of tools. It's not a recommendation to use all of them — it's a map of the landscape so you can make informed choices. Most teams use a fraction of this list, but knowing the full terrain means you're choosing deliberately rather than defaulting to whatever you encountered first.
The 26 methodologies and frameworks
Tools are the implementation. Methodologies are the thinking. The series covered 26 distinct frameworks, models, and approaches:
Delivery and planning GitOps, DORA metrics, OKRs, Agile/Scrum, Kanban, trunk-based development, INVEST criteria, #NoEstimates
Architecture and design ADRs (Architecture Decision Records), CAP theorem, CQRS, SOLID principles, DRY, YAGNI, Jobs-to-be-Done (JTBD)
Testing TDD (Test-Driven Development), BDD (Behaviour-Driven Development), AAA pattern (Arrange-Act-Assert), the testing trophy
Security DevSecOps, STRIDE threat modelling, OWASP Top 10, SLSA (Supply chain Levels for Software Artefacts), SBOM (Software Bill of Materials)
Observability and reliability SLO/SLI/SLA framework, SRE error budgets, RED method, USE method, FinOps maturity model, SPACE framework (developer experience)
Each of these gets a dedicated section in the relevant post — not just a mention. The goal throughout was to explain why a methodology works, not just what it prescribes.
The 32 failure modes named
One of the most consistent pieces of feedback from engineers is that the "what goes wrong" sections were the most valuable. Every post ends with a named list of the failure modes specific to that phase.
Naming failure modes matters because recognition is the first step to prevention. If you can look at your team's current state and say "we're doing the distributed monolith anti-pattern" or "this is alert fatigue in the making," you have a handle on the problem before it fully materialises.
A selection of the 32 named across the series:
From architecture: the distributed monolith, premature microservices, architecture-by-trend decisions, the schema trap.
From development: the solution trap, the quality ratchet, review theatre, the untouchable module.
From testing: the false confidence problem (tests that pass while production bugs exist), the e2e-first strategy, testing implementation rather than behaviour.
From delivery: the deployment event (high-ceremony, low-frequency releases), push-based CI with cluster credentials, the click-configured pipeline.
From operations: alert fatigue, the cause-based page, the missing runbook, the solo rotation.
From process: agile theatre, the sprint-as-deadline, velocity obsession, retrospectives with no follow-through.
From improvement: gaming DORA metrics, comparing teams on DORA scores, the debt sprint that never happens.
The 8 programming languages
The series is deliberately language-agnostic — the practices apply regardless of your stack — but specific examples and tooling recommendations are given for the major ecosystems.
JavaScript / TypeScript — the most extensively covered, reflecting the language's dominance in modern web development. Specific tooling for pnpm, Prettier, ESLint, typescript-eslint, Jest, fast-check, Playwright.
Python — second most covered. uv, Black, Ruff, mypy/pyright, pytest, Hypothesis, Bandit.
Go — third. go.mod / go.sum, gofmt, golangci-lint, Terratest.
Java / JVM — Gradle, Maven, Spring, Testcontainers (which originated in the Java ecosystem).
Rust — rustfmt mentioned in the toolchain post.
Ruby / Rails — Brakeman (SAST) mentioned in the security post.
Plus language-agnostic coverage of Docker, Kubernetes, Terraform, and OpenTelemetry — which have SDKs and tooling across all ecosystems.
Phase by phase: what each post covers
Here's the complete series with a one-line summary of each post's core argument — useful if you're deciding where to start or which to share with a colleague.
Post 0 — The Modern SDLC: A Field Guide The series overview and index. Start here if you're new to the series.
Post 1 — Conception and Discovery Most projects fail before a line of code is written. Seven steps from problem to project brief.
Post 2 — Architecture and System Design Every architectural decision is a trade-off. Start with a modular monolith. Document decisions in ADRs.
Post 3 — Developer Toolchain A new engineer should be productive in under ten minutes. If they aren't, that's toolchain debt.
Post 4 — Agile Planning Agile is a thinking framework, not a ceremony schedule. Measure flow, not velocity.
Post 5 — Development Practices Code is read far more than it is written. Optimise for the next reader, not the current author.
Post 6 — Testing Strategy Most teams write the wrong tests. Integration tests against real dependencies catch the bugs that actually reach production.
Post 7 — CI Pipeline A CI pipeline has one job: fast, accurate feedback on every change. Under ten minutes, zero false positives.
Post 8 — DevSecOps Security found in the editor costs minutes. Security found in production costs millions. Shift left is a financial decision.
Post 9 — Infrastructure as Code If it was clicked in a console, it doesn't exist. Infrastructure is code: reviewed, versioned, and automated.
Post 10 — Containers and Kubernetes Containers eliminate environment drift. Kubernetes earns its complexity at scale — not before.
Post 11 — Continuous Delivery and GitOps The best deployment is the one nobody notices. Git is the source of truth; automation is the executor.
Post 12 — Release Management Every environment is a gate, not a destination. Code earns its way to production by passing quality criteria.
Post 13 — Observability Metrics tell you something is wrong. Logs tell you what happened. Traces tell you why. You need all three.
Post 14 — Alerting and On-Call Alert on symptoms, not causes. Alert fatigue is a safety issue. The quarterly alert audit is the fix.
Post 15 — Incident Management and Post-Mortems Incidents are inevitable. Blameless post-mortems are how you stop having the same one twice.
Post 16 — Platform Engineering and FinOps A platform team's job is to make other engineers faster. A FinOps practice makes the cost of that speed visible.
Post 17 — DORA Metrics and Continuous Improvement DORA metrics are a diagnostic tool, not a scorecard. They tell you where the constraint is. The series tells you what to do about it.
Where to start if you're not starting at the beginning
The series is designed to be read in order — each phase builds on the previous one. But if you're joining mid-series, or want to share a specific post with a colleague facing a specific problem, here's a map by problem type.
"Our deployments are scary and infrequent" → Post 11 (GitOps), Post 12 (Release Management), Post 7 (CI Pipeline)
"We keep having the same production incidents" → Post 15 (Incident Management), Post 13 (Observability), Post 14 (Alerting)
"Our tests don't catch bugs before production" → Post 6 (Testing Strategy) — specifically the Testcontainers section
"Our engineers spend too much time on infrastructure, not product" → Post 16 (Platform Engineering and FinOps)
"Our cloud bill keeps growing and nobody knows why" → Post 16 (FinOps section)
"We started a new project and don't know where to begin" → Post 1 (Conception), Post 2 (Architecture), Post 3 (Toolchain) — in that order
"Security is always a last-minute blocker" → Post 8 (DevSecOps) — specifically the threat modelling and gatekeeper sections
"Our code review process is slow and produces noise" → Post 5 (Development Practices) — the PR size and comment convention sections
"We're doing agile but nothing feels like it's improving" → Post 4 (Agile Planning) — the retrospective follow-through section and flow metrics
"We want to measure whether our engineering is getting better" → Post 17 (DORA Metrics) — and the DORA Quick Check at dora.dev
The thread running through all 18 posts
Looking back across the series, one principle appears in every phase even when it isn't named explicitly:
Reduce batch size and shorten feedback loops.
Small PRs over large ones. Frequent deployment over infrequent. Integration tests that run in CI over end-to-end tests that run before launch. Pre-commit hooks over CI-only checks. Blameless post-mortems that produce three action items over retrospectives that produce twelve. Environment parity that catches bugs in staging over manual testing that catches them in production. Alert on symptoms now over monitoring dashboards you check occasionally.
Every practice in this series is, at its core, an application of this principle. Smaller batches are easier to verify, easier to debug, and easier to roll back. Shorter feedback loops catch problems earlier, when they're cheaper to fix. The practices that produce elite DORA scores all reduce batch size and feedback loop length simultaneously.
If you implement nothing else from this series, implement that principle. Ask it of every process decision: does this make our batches smaller? Does this shorten our feedback loop? If yes, move toward it. If no, be sceptical.
Thank you for reading
Eighteen posts. Forty-nine thousand words. One principle.
The series is complete, but software development keeps moving. If a section becomes outdated, if a tool recommendation shifts, or if a new practice emerges that belongs in this canon — the conversation continues in the comments.
If the series has been useful to you, sharing a specific post with one engineer on your team is the most valuable thing you can do. The ideas here compound when a whole team holds them, not just one person.
The complete series index lives at Post 0.
