Slow down to speed up: the engineering case for an unhurried start
Rushing the first week of a project feels productive and usually costs the most time later. Why I spend longer on the problem before touching the solution, with NASA's cost data behind it.
There is a point at the start of every project where the pressure is to show movement. Order the parts, open the CAD, write the first function. Something visible feels like progress.
I have learnt to resist that for a little while. Not for long, and not out of caution for its own sake. The first few days decide what the next few months are spent on, so they are the cheapest place to get things right.
What slowing down actually means
It does not mean writing a long document nobody reads. It means answering a few plain questions before building anything, and writing the answers down where everyone can see them.
What problem are we solving, and for whom? What does done look like, in numbers someone could check? What are we assuming, and which of those assumptions would hurt most if it turned out wrong? What is out of scope?
Most of the time the answers are quick. Occasionally one of them is not, and that is exactly the question that would have surfaced in month three as a redesign.
The cost of finding it later
NASA's Johnson Space Center studied how the cost of fixing an error grows with the phase in which it is found. They used three different methods on hardware and software systems similar to a spacecraft or small satellite. All three show the same shape: the same requirements mistake costs a few times more to fix in design, tens of times more in test and over a hundred times more in operation. [1]
The figures below come from their total cost breakdown method. The exact multipliers depend on the project, and a small embedded product is not a satellite. The direction is what matters, and it matches what most engineers see on much smaller jobs.
| Phase the error is found | Relative cost to fix |
|---|---|
| Requirements | 1x |
| Design | 3x to 4x |
| Build | 13x to 16x |
| Test | 61x to 78x |
| Operations | 157x to 186x |
The reason is not mysterious. An error found on paper costs an edit. Found in a PCB, it costs a respin and a few weeks. Found on site, it costs travel, downtime, a rework plan and some trust.
- Download the Python script that produces every figure in this article
- Download the computed values (JSON)
Sources: [1]
Where an unhurried start pays off
In my own work a few habits do most of the heavy lifting. None of them are new. They just get skipped when a deadline is close.
- Write the acceptance test firstBefore designing a controller or a board, write how you will know it works. A number, a method and a pass condition.
- List the assumptionsSupply voltage, ambient temperature, network availability, what the operator will actually do. Mark the ones nobody has confirmed.
- Check interfaces earlyConnectors, protocols, units and data formats between your part and someone else's. Most integration pain lives here.
- Make the system observableLogs, status LEDs, timestamps and data age. If you cannot see what it is doing, every fault takes longer to find.
- Separate verified from expectedKeep a clear line between what has been measured and what is still a design intent. It stops a hopeful number becoming a claim.
The speed comes back later
The payoff shows up in places that are easy to miss. Fewer design reviews that reopen old decisions. Fewer surprises in commissioning. Faults that take an hour to find instead of a week, because the system was built to be looked at.
Toyota's production system builds the same idea into the line: stop when something is wrong, fix the cause, then carry on. Stopping looks slow in the moment. Over a year it is what makes the line fast. [2]
So when I take a bit longer at the start of a project, that is the reason. It is the fastest way I know to finish.
Sources: [2]
Sources and further reading
Cost factors are quoted from Table 8 of the cited NASA study and redrawn by the linked script.