When I talk about speed in software, I don't mean runtime performance or benchmarks. I mean development velocity: how rapidly a system can be changed over time.

It's about how fast you can find out whether a change was a mistake.

Correctness is Feedback

Being wrong is unavoidable. We will all write bugs, and if any of us were judged by our worst commit, there wouldn't be a developer left working. We can aspire to do things perfectly 99.9% of the time, but eventually we all write our thousandth line of code.

Correctness has to come from systems that tell us, quickly and cheaply, when we're wrong.

Speed, Precisely

Long-term velocity isn't maximized by urgency or heroics. It's the steady ability, over time, to make changes. Ideally, those changes are positive, but that's not something we can assume. We want to know immediately if the changes in practice live up to the changes in our heads.

If getting this feedback causes friction--if it's complicated to gather or cognitively expensive to understand--it won't happen as often. Iteration slows, not because people are lazy, but because the cost is too high.

If velocity is the goal, the interface to feedback has to be cheap. A change isn't real until it's exercised.

Push-Button Verification

Practically, we need to launch the system, have it execute the desired behavior, and observe the results. To make this cheap, we need to put it behind a simple interface. I imagine it as a big button: press button, get result.

Constructing this button--whatever it actually looks like--is almost certainly not trivial or fast. The button itself may be slow in operation as it builds or tears down a little universe. What matters isn't the shape of the button, but that pressing it doesn't require remembering how the system works.

When the button exists, it is a phase transition: from intricate manual steps and careful log reading to allowing software to manage those problems.

The existence of the button also has downstream effects. It externalizes knowledge and centralizes execution. A new hire doesn't have to ask how to build the system; they can see for themselves. If the build changes--more steps, different compilers, new reporting scripts--it can change in one place and the entire team is immediately up to date. The button becomes the canonical truth, and it lives in source control.

These types of buttons are not always easy to create. The systems we work on are complicated and often composed of many moving parts. That complexity should make us more desperate for a button, not less. The complexity has to exist somewhere, either in a script or in your head. You either pay the cost once, up front, or a thousand times over the rest of the project.

Pressure and Time Are the Same Enemy

Sometimes pressure is real. Not the abstract kind--not a deadline or a demo--but the kind where the system is wrong right now. Data is being corrupted. Users are locked out. Waiting makes things worse.

In those moments, heroics can be necessary. Late nights, hacky workarounds--whatever it takes. But heroics don't scale, and they don't last. Systems that rely on brilliance, deep context, or someone just knowing how this works are fragile under both pressure and time.

Everyone loses context eventually.

This is why heroics don't compound. They can solve the immediate problem, but unless they make the next answer cheaper, they reset the clock.

Systems that survive pressure and time don't ask people to carry the system in their heads. Systems that depend on memory, brilliance, or heroism are already on a clock. The question isn't whether they'll fail--it's whether they'll fail loudly under pressure, or quietly as time erodes what people once knew.

What Actually Scales

Sustained development speed emerges from systems that make being wrong cheap. Cheap wrongness requires push-button feedback. Any feedback that depends on memory or heroics is not cheap enough.

This is what makes high-value changes possible--quickly, correctly, and with confidence--whether during a crisis or six months after everyone has moved on.

When systems take responsibility for correctness, people don't need bravery to do their jobs. They need a way to find out when something is wrong.