Systems
The Power of Simplification: Lessons from Spacecraft Design
The Space Shuttle had 2,000 switches and stopped flying. The Soyuz had 63 and still flies.
This is the fourth installment in a series on first-principles thinking. The series works through six ideas: question every requirement, make requirements less dumb, delete unnecessary parts, simplify and optimize, accelerate cycle time, and automate last. This piece is about the third one, deleting unnecessary parts.
The first time I saw the inside of a Soyuz, I was working at Johnson Space Center, and I was taken aback by how sparse and simple it was.
I loved the Orbiter. I loved all of it, the switches and the dials and the backup systems behind the backup systems. The Shuttle’s flight deck had over 2,000 switches. The Soyuz cockpit, in 1997 when I was working with it, had 63. It looked sparse. It looked like a lot less airplane.
I worked in the Mission Operations Directorate and Crew Operations, so I saw what each one cost to fly. The Shuttle needed extensive training and meticulous procedures, because there was so much of it to know. The Soyuz you could mostly understand by looking at it.
The Shuttle was designed for a two-week turnaround between flights. In practice it took six to twelve months of spot fixes and refurbishment every time. Every backup system was one more thing to maintain, and every switch was one more thing a crew could get wrong. The program was retired in 2011 because the operating costs and the safety record couldn’t be sustained.
The Soyuz first flew in 1967 and is still flying, with minimal design changes, on one job: carry people to orbit and bring them back. It never had the Shuttle’s cargo bay. Russia put the first piece of the International Space Station, the Zarya module, into orbit on a Proton-K in 1998 without it, and launched Zvezda, Poisk, Nauka, and Prichal the same way.
The more capable vehicle stopped flying. The one with only what it needed is still going.
So before you optimize anything, ask what can be removed. Every feature, control, and process step is a place for something to break. If you take it out and nothing breaks, it was never necessary. If a rule or a feature has grown over time and nobody can say why, that’s complexity creep, and the answer is usually to delete it. Most of us optimize by adding. Apple’s run came mostly from removing things. The companies that move fastest are the ones that cut approval steps, not the ones that add tooling.
I’ve come to think a lot of complexity just means we didn’t understand the problem well enough to leave things out.
If you want homework: pick one thing at work that’s gotten too complicated and see what you can rip out.