// CONTENTS
John Carmack, the programmer behind Doom and Quake, once explained what it takes to build some grand new thing. It wasn’t money.
You need enough pizza and Diet Coke to stick in your refrigerator, a cheap PC to work on, and the dedication to go through with it.
That’s from David Kushner’s book Masters of Doom, and I’ve never read a better summary of how I got started. I released my first game at ten, on a floppy disk in my father’s computer shop in southeast Portland, around the same time Doom was originally released. The capitalization was zero.
Speaking of Coke, a quick tangent.
In 2014 I was at the Coca-Cola Store in Las Vegas, overseeing installation of the Polar Bear Game. A security guard found me in an employees-only area and asked me to identify myself.
So I told him what I was there to do, and who I was with: CRACK, IDL Worldwide. That’s the company I worked for, followed by its better-known parent company.
Said fast, that comes out as “Crack. I deal worldwide.”
He did a double take. I had to clarify.
Anyway. More than 25 years of building later, I have a philosophy about how software should be made. This is it, and where it has led me.
Iteration Speed Is Everything
If I could keep only one rule, it would be this one. The faster you get from an idea to seeing whether it works, the better everything else becomes.
I’ve worked that way from the start: a small step, run it, look at what happened, change it. Later someone named it extreme programming and wrote books about it. I was doing it before the term was coined. I thought it was just called programming.
It’s why I prototype before I commit. When I don’t know whether something can work, I build a spike: a small throwaway experiment whose only job is to answer one question. An afternoon of research or a rough prototype is the cheapest insurance in software.
It’s also why I care about speed in the literal sense. A slow computer, a slow build or an oversized download taxes every single iteration. On Call of Duty: Puzzle Ops I designed a new way of streaming assets that took the game from 1 GB to 400 MB. On Back 4 Blood I worked on a build farm in the cloud. Neither is glamorous. Both buy back time, and time is what iteration is made of.
That’s all productivity is, to me: the length of the loop between an idea and its result. In 2013 the 3D artist Jon Young and I entered a three-month game challenge with one month left, and won an award anyway. A month is plenty when the loop is short.
Fast Is Not Sloppy
Martin Fowler has a sketch that settles a lot of arguments. Two projects on a graph. One skips design and races ahead. The other spends time on design and starts slower. Then the first line flattens as the mess piles up, and the second keeps climbing and crosses it.
He calls the crossing the design payoff line, and in his Design Stamina Hypothesis he says when he thinks it arrives: “usually weeks not months.”
Weeks. Technical debt is a loan against that curve, and sometimes a loan is the right call. But the interest starts almost at once.
I learned this in hardware, where you can’t patch a circuit board after it ships. I designed RackVax Electric in levels: modules and their inputs and outputs at the top, the circuit details isolated below, so any board could be swapped on the bench. It shipped worldwide with zero warranty returns.
Testing is the same bet. I worked in QA at Intel, where I learned that almost every bug is a disagreement between what someone meant and what someone made. Tests find the disagreement while it’s still cheap.
Bugs, Moths and Permission
Speaking of bugs. In 1947, the team running Harvard’s Mark II computer found a moth stuck in a relay. They taped it into the logbook and wrote: “First actual case of bug being found.”
Grace Hopper worked on that machine, and she told the story so often that people came to credit her with the word itself. She didn’t coin it. Engineers had been calling faults “bugs” since Edison’s day, which is the whole joke: after decades of bugs that weren’t insects, here at last was a real one.
As a former QA person, I admire that logbook entry. It’s the most famous bug report in history, it’s one line long, and it has the bug attached.
Hopper is also known for another line: “It’s easier to ask forgiveness than it is to get permission.”
More on that later.
Light and Fast
Then there’s process. I’m done with Agile and Scrum. What I do now is ad hoc planning and coordination, on purpose. We plan when there’s something to plan, and we talk when there’s something to say. The project management is the lightest that fits the project in front of me, with as little overhead as I can get away with.
I’ve seen the alternative: endless meetings held for the sake of having meetings, and Agile and Scrum rituals that turn robotic and stop serving the project and the team they were meant for.
I treat process as an investment. If it doesn’t give you back more time than you put into it, do something differently.
That isn’t the same as having no plan. I want milestones, so everyone knows where we’re going. I want tasks, so everyone knows what’s next. And I want the plan to adapt, because of a picture called the cone of uncertainty: at the start of a project, an honest estimate can be off by a factor of four in either direction, and the range narrows only as you make decisions and learn things. A plan that can’t change was drawn at the widest part of the cone.
And your team matters more than any of it. I’ve won that game challenge on a team of two and led a team of six on Sensorium Galaxy, part of a larger team of over 60. A few of the right people with a light process will outrun a crowd with a heavy one.
The Boring Parts
Some of the most valuable work I’ve done would bore you at a party.
On Sensorium Galaxy, my team built out the source control, the repository structure and tooling, and the build system. Nobody puts that in a trailer. But decide early how the repository is laid out and how branches work, automate the build, and let CI tell you within minutes when something breaks, and everyone on the project gets that time back every day.
The same goes for tools and process. When I notice I’m doing the same thing by hand every time, I automate it. The workflow is a product too, and it’s never finished.
Neither am I. Working on a World of Warcraft server emulator taught me design patterns and pathfinding. RackVax taught me persistence. Every project has handed me something the next one needed.
Failure
On the first RackVax prototype, a chip went into oscillation, squealed and burned itself out. The cause was an undocumented error in its datasheet.
I still have that board.
Failure is information, and usually the expensive kind, so you may as well keep it. I try to be an optimist about whether a thing can be built and a pessimist about how long it will take. You need the first to start and the second to finish.
Done
The Cult of Done Manifesto, which Bre Pettis and Kio Stark wrote in 2009, ends on a line I love: “Done is the engine of more.”
Finishing a thing is what earns you the next thing. Shipped beats perfect.
I’d add one condition. It’s not done until it’s documented.
Here’s the test. Think of yourself six months from now, trying to remember why it works the way it does. That person has forgotten everything and is in a hurry. Write it down for them.
Where I’ve Arrived
Everything above is older than AI agents. Then the agents showed up and did something interesting to the list. They made iteration close to free.
With speed taken care of, every other item became the bottleneck. An agent with no design runs straight into Fowler’s curve. An agent with no plan lives at the widest part of the cone. An agent with no documentation forgets a decision you made an hour ago.
So I packaged the philosophy. SpecDevShip is a pack of 19 agent skills that wraps an AI coding agent in the process I’d been running by hand: Spec, Dev, Ship.
This site was built with it, and Stop vibe-coding tells that story.
It has a light tier for everyday features and fixes, because overhead should be low, and a full tier for new apps and real architecture, because design pays for itself. It builds from a numbered list of tasks, with tests and a commit for each one. And it ends with a walkthrough and a changelog entry, because it’s not done until it’s documented.
It also has approval gates, so the agent can’t quietly change a plan I’ve signed off on. Which brings me back to Grace Hopper, as promised. My position is that forgiveness is for people. Agents can ask permission.
Pizza, Diet Coke, a cheap PC and the dedication to go through with it. I’d add a spec.