What a space shuttle disaster taught me about software specs
Slides are for selling. Specs are for thinking.
The Space Shuttle Columbia disaster confirmed something I had already learned on the factory floor: when you compress complex engineering into bullet points, people die.
On a Saturday morning in February 2003, I woke up in a Los Angeles hotel ready to fly to Dallas via Las Vegas. I turned on the TV and saw the news. Space Shuttle Columbia had broken apart over Texas during re-entry.
Hours later, I was driving a rental car on a Dallas highway. The digital billboards were flashing instructions. Do not touch space debris. Report it. A surreal moment that has stayed with me for over two decades.
What stayed with me longer was something I read in the NASA Columbia Accident Investigation Board's final report. The board found that NASA had drifted away from traditional technical reports. Written documents that forced clarity, precision, and complete reasoning. Instead, they had come to rely on PowerPoint slides to communicate complex engineering analysis.
When engineers compressed risk assessments into bullet points, critical context and caveats were lost. The board put it bluntly. It was easy for a senior manager to read a PowerPoint slide and not realize it described a life-threatening situation.
Reducing engineering judgment to slideware contributed to a culture where weak signals of danger were not seen for what they were.
I have watched this same pattern repeat in every industry I have worked in for 30 years.
I started my first software company at 22. I learned my craft in the 1990s, when we called them specs, and we wrote them properly. Waterfall was how you built software. You defined the problem in writing. You forced yourself to think through every dependency, every edge case, every interface. You wrote it down because the act of writing was the act of understanding.
Agile and iterative methods have rightly taken over. Nobody builds software the way we did in 1991. I do not argue with that.
But across every company I have built, every turnaround I have run, every production line I have commissioned in 37 countries, one observation has held. If a team does not write clear specifications at the start of a project, they do not actually understand the customer's needs. They do not have a shared vision. And without that, no amount of velocity will deliver a high-quality solution.
The problem is not that slides exist. The problem is that slides have replaced thinking in places where thinking is the whole job.
A slide deck compresses. A specification expands. One is designed to persuade a room in 20 minutes. The other is designed to survive contact with reality for over 20 months.
When you write a specification, you are forced to answer questions that a slide lets you skip. What happens when the input is outside the expected range? What does the system do when the network fails? Who owns the decision when requirements conflict? These are not academic questions. They are the questions that determine whether a production ramp takes three months or eighteen.
I have seen this in diagnostics manufacturing, where I run Ginolis today. A customer develops an assay in the lab. It works perfectly on the bench. Then they hand it to a production team with a slide deck and a few bullet points describing the process parameters. Twelve months later, the production line still does not run at specification. The reason is always the same. The transfer document did not force anyone to think through the gap between lab conditions and factory conditions. The bullet points looked clear. The reality was not.
The lab-to-fab gap is not a technology problem. It is a documentation problem. It is a thinking problem.
At Danaher, I learned how the best companies in the world build processes that do not depend on one person. The Danaher Business System runs on written standard work. Not presentations. Not summaries. Written procedures that describe exactly what happens, in what order, with what tolerances, and what to do when something deviates.
That system works because writing forces precision. A bullet point that says "ensure quality parameters are met" means nothing on a factory floor at two in the morning. A specification that says "dispensing CV must be below 0.6 per cent for volumes between 1 nanoliter and 1,500 microliters, verified every 500 cycles using the following test protocol" means something a technician can act on.
The difference between those two sentences is the difference between a product that ships on time and a product that misses its launch window by a year.
Three things I have observed across 30 years of building and fixing technology companies.
The companies that write clear specifications before building have shorter development cycles, not longer ones. The time spent writing is recovered three times over in reduced rework, fewer misunderstandings, and faster decisions when trade-offs arise.
The teams that rely on slides for technical communication consistently underestimate complexity. A slide can hold six bullet points. A production line has six hundred decision points. The format itself creates blind spots.
The specification is not the deliverable. It is the diagnostic. If a team cannot write a clear spec, that is the signal that the problem is not yet understood. Skipping the spec does not eliminate the confusion. It just moves it downstream, where it costs ten times more to resolve.
A CEO who cannot do the work cannot lead the people who do it. I have always believed that. The same logic applies to specifications. A leader who cannot write a clear description of what the product must do, who it serves, and how it will be tested has not done the thinking required to lead the project.
I am an old school guy in this regard. I write my own quotations. I use the ERP myself. When I took over Ginolis, I built the turnaround plan with 1,200 individual tasks, each with an owner and a deadline. Not a slide deck. A document. Because the document is where the work lives.
NASA lost seven astronauts because, among other failures, critical engineering analysis was compressed into a format that made danger look manageable. That is the extreme case. The everyday version is less dramatic but structurally identical. Projects fail, products miss their market window, production ramps stall, and customers wait because someone decided that a slide deck was a sufficient substitute for a written specification.
The practical test is simple. Take the most important technical decision your team is currently making. Find the document that describes it. If that document is a slide deck, ask yourself one question. Could a person reading this document, with no other context, understand the full scope of the risk and the full set of assumptions behind the recommendation?
If the answer is no, the document is not a specification. It is a sales pitch dressed as engineering.
The companies that will lead the next decade of diagnostics, microfluidics, and precision manufacturing will be the ones that write things down properly before they build. Not because writing is old-fashioned. Because writing is where the thinking happens. Everything else is presentation.
Kauko Väinämö is CEO of Ginolis