Technical Excellence
// Technical Excellence · Guiding Principles

Nine Phases, Nine Principles

One principle for each phase of the software lifecycle, from the first question about a requirement to the day a system has to change. Every line is quoted word for word from an essay on this site, and each one links back to the essay it came from.

// how to use this page

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. Build and Deliver carry one line each. 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

01

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.

from Beyond the Codebase
02

Design

What shape will hold, and what will each choice cost later?

Decide on merit, not momentum.

from Cognitive Bias Is Enemy Number One
03

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.

from Blocking, or Preference?
04

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.

from Not Run Is Not Passing
05

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.

from The Pipeline and the Cache: Forces 05–06
06

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.

from Five Deployment Strategies. One Personal Favourite.
07

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.

from Every Error Has an Address
08

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.

from A Declined Card Is a Person
09

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.

from The Stack Aged. The Categories Didn't.

// continue exploring