The Modern Software Development Lifecycle: A Field Guide for Engineers
The Modern Software Development Lifecycle: A Field Guide for Engineers
Series: The Modern SDLC · Post 0 of 17 This is the starting point. If you found a later post first, start here.
Most engineering content focuses on individual tools or techniques in isolation. "How to write better tests." "A guide to Kubernetes." "Why you should adopt GitOps." All useful — but none of them answer the harder question: how do all of these pieces fit together into a coherent system for building and delivering software well?
That's what this series is for.
Over 17 posts, we'll walk the entire software development lifecycle from the moment an idea exists to the moment it's running in production — and everything that happens after that. Not as a theoretical framework, but as practical guidance grounded in how modern engineering teams actually operate.
Each post stands on its own. But read as a series, they build into something more useful: a complete picture of modern software development, from conception to continuous improvement.
Who this series is for
Engineers at any level who want to understand not just how to do the individual things, but why they fit together the way they do.
If you're a junior or mid-level engineer, this series will give you the mental model that takes years to develop through experience — the understanding of how CI connects to CD, how observability connects to incident response, how the decisions you make at conception affect what's painful in production.
If you're a senior engineer or tech lead, it's a reference and a calibration. You'll agree with most of it, push back on some of it, and hopefully find a few things worth taking back to your team.
If you're an engineering manager, it's a map of the terrain your team operates in — useful for spotting gaps and having more informed conversations about where to invest.
The 17 phases
Modern software delivery isn't a waterfall — it's a continuous loop. Each phase feeds into the next, and what you learn in production feeds back into how you conceive the next project. The phases below follow the natural flow from idea to operation, but in practice they overlap and inform each other constantly.
Conception and planning
Phase 1: Conception and Discovery Before a line of code is written. Problem framing, stakeholder mapping, user research, feasibility assessment, and success metrics. The phase most teams skip and most projects fail in.
Phase 2: Architecture and System Design The decisions that shape everything downstream. Monolith vs microservices, synchronous vs asynchronous, database strategy, CAP theorem in practice, and why boring technology is usually the right technology.
Phase 3: Repo Setup and Developer Toolchain Your toolchain is either a force multiplier or a tax. Monorepo vs polyrepo, trunk-based development, linting, formatting, pre-commit hooks, and the one-command local setup that makes onboarding fast.
Phase 4: Agile Planning and Iteration What modern agile actually looks like in practice — not ceremony for its own sake. OKRs, story craft, estimation, sprint cadence, backlog health, and the flow metrics that matter more than velocity.
Development
Phase 5: Development Practices and Coding Standards The practices that separate teams who ship confidently from teams who ship anxiously. Code quality, TDD, code review done right, documentation as code, SOLID principles, and feature flags.
Phase 6: Testing Strategy Why the testing trophy beats the testing pyramid. Unit tests, integration tests with real dependencies, contract testing, end-to-end tests used sparingly, and where security and chaos testing fit in.
Delivery
Phase 7: Continuous Integration The CI pipeline as the nervous system of your delivery process. Platform choice, the five pipeline stages, parallelisation, caching, security gates, artefact signing, and the 10-minute rule.
Phase 8: DevSecOps and Shift-Left Security Security as everyone's job, not the security team's gate. Threat modelling, secrets management, supply chain security, OWASP Top 10 mitigations, and the culture that makes it stick.
Phase 9: Infrastructure as Code Treating your cloud like a codebase. Terraform, GitOps for infrastructure, drift detection, policy as code, and the pitfalls that catch teams who get the basics wrong.
Phase 10: Containers and Kubernetes What containers actually are and why they matter. Dockerfile best practices, the core Kubernetes objects you'll use every day, Helm, service mesh, and — critically — when Kubernetes is the wrong choice.
Phase 11: Continuous Delivery and GitOps Making deployment boring. The GitOps model, environment promotion, progressive delivery strategies (canary, blue-green, feature flags), release gates, rollback that works, and DORA metrics.
Phase 12: Release Management and Environments How changes move from development to production safely and predictably. Environment parity, ephemeral preview environments, versioning strategy, change management for regulated environments, and the release readiness checklist.
Operations
Phase 13: Observability — Metrics, Logs, and Traces The three pillars and why you need all three. OpenTelemetry, structured logging, distributed tracing, SLOs and error budgets, and the observability maturity ladder.
Phase 14: Alerting and On-Call Operations Alerting that doesn't burn your team out. Symptom-based alerting, SLO burn rate alerts, severity levels, runbooks that work at 3am, on-call rotation design, and the quarterly alert audit.
Phase 15: Incident Management and Post-Mortems How to respond when things go wrong — and how to make sure they go less wrong next time. The incident lifecycle, IC role, blameless post-mortems, the 5 Whys, and action items that actually get done.
Phase 16: Cost Optimisation and Platform Engineering FinOps as an engineering discipline and the platform team as a product team. Cloud cost visibility, the biggest savings opportunities, Internal Developer Platforms, golden paths, and DevEx metrics.
Phase 17: Continuous Improvement and DORA Metrics Measuring whether you're actually getting better. The four DORA metrics, the levers that move each one, retrospectives that produce change, tech debt as first-class work, and the anti-patterns that make teams feel busy while standing still.
A few things worth saying upfront
This is opinionated. Engineering has genuine trade-offs, and I've taken positions on most of them. You should push back where your context differs — context always matters. But "it depends" without a recommendation is rarely useful, so throughout the series I'll give you the default I'd reach for and explain when to deviate from it.
The phases interact. The decisions you make in Phase 2 (architecture) affect what's painful in Phase 13 (observability). The practices you adopt in Phase 3 (toolchain) determine how fast Phase 7 (CI) can run. Reading the series end-to-end is more valuable than reading individual posts in isolation — though individual posts are written to stand alone.
Nobody does all of this perfectly. The series describes what modern best practice looks like, not what every team achieves. Use it as a compass, not a checklist. Start with the phase that is causing the most pain right now and work outward from there.
The most important phase is the one you're skipping. Most teams have gaps in their processes that they're aware of but haven't prioritised. Delivery is fast but testing is weak. Testing is strong but observability is missing. Observability is good but incidents leave no learning. The value of a complete picture is knowing which gap to close next.
How to use this series
If you're starting a new project: Read phases 1–4 before writing any code. The conception and planning phases are where the most leverage is and where the least time is typically invested.
If you're inheriting a project: Start with phases 13–15 (observability, alerting, incidents). Understanding what's actually happening in production is the fastest way to understand a system you didn't build.
If you're trying to improve an existing team's process: Use the DORA metrics in Phase 17 to diagnose where the constraint is, then read the corresponding phase for the highest-leverage improvements.
If you're an individual contributor: Phases 5, 6, and 7 (development, testing, CI) are the ones most directly in your control. Start there.
The series index
Posts will be linked here as they publish. Bookmark this page.
Post 0: The Modern SDLC: A Field Guide (you are here)
Post 1: The Phase That Determines Whether Your Project Succeeds or Fails Before You Write a Line of Code (coming soon)
Post 2: The Architecture Decisions That Will Haunt You (And How to Make Them Well) (coming soon)
Post 3: Your Developer Toolchain Is Either a Force Multiplier or a Tax (coming soon)
Post 4: Modern Agile: What Actually Works vs What's Just Ceremony (coming soon)
Post 5: The Coding Standards That Separate Confident Teams from Anxious Ones (coming soon)
Post 6: The Testing Trophy: Why You're Probably Writing the Wrong Tests (coming soon)
Post 7: How to Build a CI Pipeline That Engineers Actually Trust (coming soon)
Post 8: Shift Left: How to Make Security Every Engineer's Job (coming soon)
Post 9: Infrastructure as Code: Treat Your Cloud Like a Codebase (coming soon)
Post 10: Containers and Kubernetes: What They Actually Are and When You Actually Need Them (coming soon)
Post 11: GitOps: Making Deployment So Boring It Never Wakes You Up at 3am (coming soon)
Post 12: Release Management: How to Ship Without Fear (coming soon)
Post 13: The Three Pillars of Observability: And Why You Need All Three (coming soon)
Post 14: Alerting That Doesn't Burn Out Your Team (coming soon)
Post 15: Blameless Post-Mortems: How to Turn Outages Into the Best Learning Your Team Gets (coming soon)
Post 16: Cloud Costs and Platform Engineering: Making the Right Thing the Default Thing (coming soon)
Post 17: DORA Metrics: The Four Numbers That Tell You Whether Your Engineering Is Actually Getting Better (coming soon)
If this series is useful to you, sharing it with one engineer on your team is the best thing you can do. The ideas here compound when a whole team holds them, not just one person.
Next up: Phase 1 — Conception and Discovery
