By Warren Smith, Principal Systems Engineer
About 20 years ago, I met a systems engineer (name long forgotten) who was already an old hand at developing systems.
As we talked shop, discussing systems engineering, documentation, and office politics, he relayed a story that has stuck with me through the years. As a young engineer, he landed a job working on the Space program: a choice position indeed during the 1960s and early ‘70s. By this point, the program was quite mature. Most of the system specifications and design documents had long since been completed and released before he joined the team.
As he performed his work though, he uncovered an error in one of the design specifications. Being diligent, he approached his supervisor about it. “Check it out, boss: The design document doesn’t accurately describe this subsystem.” While his supervisor agreed, the document was several years old by then, and had been released for a long time. The program had flown multiple missions and was considered a fairly mature system. Consequently, there was no budget allocated for re-performing this analysis and updating old documents.
The engineer returned to his work, but was bothered by the fact that this data was wrong. He decided to act on his own. He started working in the evenings and weekends to chase down the design. He spent hours late into the night, in front of the micro-fiche machine, an old-time magnified lightbox to view tiny photographs of the as-built drawings for the spacecraft. He sat with pencil and paper re-running the flow and concentration calculations of the subsystem at a time before calculators, much less computers.
After spending all his spare time for over a month, it was done. He took the work to his boss and showed him what he had accomplished. “This is terrific, and your dedication is commendable!” his boss said. I’ll definitely release this updated design document into the system. It was revised and released.
Sometime later, a failure occurred during one of the space missions. A team of engineers and scientists assembled to determine a fix. They pulled the latest set of drawings and design documents they would need to figure out how the crew could fabricate a solution out of parts available on-board the spacecraft. The crew stood ready to rig a solution based on their instructions.
One of the documents pulled was that young engineer’s design document. The section they turned to was the section he had updated. The analysis they used was his CO2 concentration and flow calculations.
You see, the failure was caused when an explosion in an oxygen tank from faulty wiring caused the CO2 levels to start rapidly rising, threatening the crew with asphyxiation. Thanks to the feverish efforts by the ground team, the crew themselves, and yes, by an unnamed engineer who diligently dogged the details, the crew of Apollo 13 returned home safely.
Details matter. Engineers understand this. At Vitech, we understand this. Sometimes we say our tools “perform the technical bookkeeping so you don’t have to”. What we mean by this is that our tools strive to manage the thousands of technical details to expose design discrepancies like that one missed by so many, but luckily found by one stubborn, diligent young Apollo engineer, all those years ago.
