The costly mistakes in software tend to be made in one phase and paid for in another. A design that never asked how its feature would be tested, deployed and watched in production usually passes its review. The bill arrives later, in whichever phase it skipped.
In a 2020 draft on architecture and design, I wrote that the design phase is already the time to think about how a feature will be developed, tested, built, deployed, monitored and changed. This page reads the whole lifecycle that way, as one piece of work. Each of the nine phases gets a question to ask, one principle to carry, and, where the site has earned them, up to two supporting lines. Under most phases, a folded list holds the further lines the essays have earned, each one quoted word for word. Build and Deliver carry no supporting line. They are the two phases this site has written least about, and padding them would only hide the gap.
Read a phase before it starts, while its principle is still cheap to follow. The phases themselves are defined in How Software Gets Built, what AI changes inside each one is mapped in AI Across the Full SDLC, and the long-form essays for each phase are being written, one at a time, in Part VI of Technical Excellence.
The Nine Phases
Analyze
What is the problem, who has it, and is it worth solving?
A proposal that only lists benefits was not analyzed; it was sold.
An estimate does not need to be right. It needs to be close, fast, and defensible enough that the room moves on to the actual decision instead of arguing about the arithmetic.
from Precision Is Not the Point
More from the essays · four lines
I have never found a better discipline than this: before you optimise a system, name one real person who is harmed when it fails, and build for them.
from A Declined Card Is a Person The most expensive mistakes in software are not made during development. They are made before development starts – in how requirements are written, and in how the domain is modelled.
from Before the First Line of Code: Forces 01–02 The question that kills most agent deployments is not "which model should I use?" It is: "what exactly is this agent supposed to do?"
from What Agents Actually Need Adopting microservices is not really a technical decision. It is a readiness decision, and you have to ask it at every level at once: are you ready as an individual, as a leader, as a team, as a company, and as a business domain, to change how you design, develop, deploy, monitor, and operate what you build?
from Are You Ready for Microservices?
Design
What shape will hold, and what will each choice cost later?
Decide on merit, not momentum.
Drawing service boundaries is drawing team boundaries.
from When Architecture Becomes a Leadership Problem
More from the essays · four lines
There is a test I use on myself. If I removed my name and title from the recommendation, would it still win on the page alone?
from Cognitive Bias Is Enemy Number One Functional requirements keep users happy; non-functional requirements keep the business alive.
from Design for the Load You Have Not Met Yet My chief architect read for fifteen minutes, then looked up and said: this is not an architecture. This is a description of code.
from The Day I Realised I Was Not Ready A model does not read your mind; it reads your contract.
from One Contract, Every Tool: How MCP Works
Develop
Will the next person be able to read this, and change it safely?
Good enough is a number we agreed on, not a question of who feels most strongly in the review.
Readability is not a courtesy to yourself. It is a bill you either pay now or hand, with interest, to whoever inherits the code.
from Five Stepping Stones to Systems That Last Outsource the typing if you like. Never outsource the answer to the only question that matters when it breaks.
from You Cannot Prompt Ownership
More from the essays · two lines
Compress the search. Do not skip the struggle.
from Seventy Percent Has to Be Yours Production does not read your prose. It runs your assumptions.
from Seventy Percent Has to Be Yours
Test
What do we know works, and what are we only assuming?
A partial with its reason written down is worth more than a pass you rounded up.
Redundancy you never exercise is not insurance. It is a guess wearing a confident face.
from Nobody Promised You 100% Uptime
More from the essays · four lines
Report the run you did, not the run you meant to do.
from Not Run Is Not Passing An eval is a test that grades instead of asserts: a golden set instead of fixtures, a scorer instead of assertEquals, a threshold instead of a green bar.
from Tests, With a Probabilistic Twist: LLM Evals 101 When an AI agent misreads a spec, it implements the misreading with complete confidence, generates tests that validate the misreading, and produces clean code that does the wrong thing coherently.
from Before the First Line of Code: Forces 01–02 Reliability is not built from what survived. It is built from what didn't.
from The Planes That Didn't Come Back
Build
Can the same source produce the same artifact, every time?
Writing the code feels like the finish line. It is closer to the starting gun – almost everything expensive happens after the commit lands.
No further lines yet: Build is the phase this site has written least about.
Deploy
Can this change reach production on an ordinary afternoon?
The goal is not to deploy less often to reduce risk. The goal is to reduce the risk in each deployment so much that you can deploy as often as the work demands.
The cloud was up. We were the incident.
from Nobody Promised You 100% Uptime If a change would break a consumer, it did not ship.
from Your API's Users Are Developers
More from the essays · one line
Before I had a vocabulary for any of this, I had a rule: no builds on Monday, no builds on Friday.
from Five Deployment Strategies. One Personal Favourite.
Monitor
When something fails, who finds out first, and how fast can they find it?
The code is what you count. The request id is what you find.
An alert that fires when nobody is on call is not an alert. It is a diary entry.
from The Signal Didn't Stop Your load balancer knows if your API is slow. Your error tracker knows if your API crashes. Nothing tells you if your AI feature is confidently wrong.
from 8 Forces Reshaping How Software Gets Built
More from the essays · three lines
A good alert is a sentence about the user, not a reading off the machine.
from Nobody Promised You 100% Uptime Error logging is not error management.
from The Engineering Philosophy Behind Every Team I Have Built Nobody is ever made a hero for the outage that did not happen.
from The Men Who Kept the Lights On
Deliver
Did the value reach the person it was meant for?
We were not processing transactions. We were keeping promises that people did not even know they were trusting us to keep.
More from the essays · two lines
The bottleneck in enterprise AI is no longer the model. It is the last mile: getting a model into a customer's real environment, safely and reliably.
from The Forward Deployed Engineer Here is the uncomfortable reframe that changes how you build: if developers are your users, then their frustration is your API's failure rate.
from Your API's Users Are Developers
Deliver has no essay of its own yet. These lines come from essays that touch it.
Change
When the ground moves, can the system and the decisions behind it move too?
The category is a decision. The tool is a lease.
"Our monolith has run for seven years, why modularise it now?" Those seven years are the bullet holes on the wing: proof of what it survived, not proof of what it can still take.
from The Planes That Didn't Come Back