The first question
When we’re brought onto a troubled project, the first thing we ask isn’t about the architecture or the deadline. It’s mundane: how do I build and run this?
The answer tells you almost everything. If it’s “there’s a wiki page” (last updated two years ago), or “ask Dave” (who left in March), or “it only really works on the old build server,” you’ve learned more about the health of that project in thirty seconds than a week of code review would tell you.
The build is the smoke, not the fire
There’s a reason this question is diagnostic. Twenty-five years ago, Joel Spolsky’s famous “Joel Test” put it second on a twelve-item list, right after source control: Can you make a build in one step? (Number three: Do you make daily builds?) He wasn’t being pedantic. The build process is a proxy for everything around it.
A team that can turn a clean checkout into a running system with one command has, almost by definition, kept its house in order: dependencies are declared, environments are reproducible, the steps are written down and exercised constantly. A team that can’t has usually let the rest slide too — the tests, the environment setup, the release process. The broken build isn’t the disease. It’s the most visible symptom of a project that has quietly stopped being reproducible.
So when the build is missing, undocumented, or “works on one machine,” we don’t file it as a chore for later. We treat it as the headline finding.
The flip side: the cheapest big win you’ll make
Here’s the part that makes this more than a red flag. On a flailing project, getting a one-step build and a basic test pipeline in place is often the single highest-leverage thing you can do — and it’s cheap.
The moment anyone can check out the code, run one command, and get a running system with a green-or-red result, three things change at once. The work becomes reproducible (no more “it works for me”). It becomes visible (you see breakage the instant it happens). And — quietly the most important — it becomes safe to change. A team that was afraid to touch the code because nobody knew what would break suddenly has a net under it. “We can’t risk it” turns into “let’s try it and see if it goes green.”
This isn’t folk wisdom. It’s the backbone of the DORA research behind our quality post: the teams that are both fast and stable are, overwhelmingly, the ones who automated build, test, and deployment. In Continuous Delivery, Jez Humble and Dave Farley boiled it down to a rule of thumb — if it hurts, do it more often, and bring the pain forward — and the first thing you automate is the build. Martin Fowler’s writing on Continuous Integration tells the same story: every commit builds and tests itself, so problems surface in minutes instead of months.
What “good” actually looks like
You don’t need a gold-plated platform to clear this bar. You need:
- One step from clean checkout to running system. One command or one click — not a twelve-item runbook only one person can follow.
- It runs somewhere other than a laptop. A CI server or pipeline that builds on every push, so “works on my machine” stops being a defense.
- A test suite that returns a verdict. Even a thin one. Green means go, red means stop — the signal matters more than the coverage number.
- Reproducible environments. The same inputs produce the same build, every time.
That’s it. It’s unglamorous, and it’s often just a few days of work. On a project that’s flailing for ten other reasons, those few days buy back the one thing every other fix depends on: the ability to make a change and know whether it worked.
Before anything else
So on a rescue, before we add a feature or chase a bug, we make sure the team can build, test, and ship in one step. It stops the bleeding, it restores momentum, and it turns a codebase people are afraid of back into one they can actually work in.
Software that’s too important to get wrong has to clear a lower bar first: it has to be something you can reliably build at all.
Sources & further reading
- J. Spolsky, The Joel Test: 12 Steps to Better Code (2000) — #2 “Can you make a build in one step?”, #3 daily builds — joelonsoftware.com
- J. Humble & D. Farley, Continuous Delivery (2010)
- N. Forsgren, J. Humble, G. Kim, Accelerate / the DORA program — dora.dev
- M. Fowler, Continuous Integration — martinfowler.com
Facing this yourself? See our related service →