|Jack Ganssle's Blog
This is Jack's occasional outlet for thoughts about designing and programming embedded systems. It's a complement to my bi-weekly newsletter The Embedded Muse. Contact me at firstname.lastname@example.org. I'm an old-timer engineer who still finds the field endlessly fascinating (bio).
NASA's Lost Software Engineering Lessons
November 7, 2018
I was reading Computers in Spaceflight: The NASA Experience and came across this quote:
Overcoming the problems of the Apollo software, NASA did successfully land a man on the moon using programs certifiably adequate for the purpose. No one doubted the quality of the software eventually produced by MIT nor the dedication and ability of the programmers and managers at the Instrumentation Lab. It was the process used in software development that caused great concern, and NASA helped to improve it143. The lessons of this endeavor were the same learned by almost every other large system development team of the 1960s: a) documentation is crucial, (b) verification must proceed through several levels, (c) requirements must be clearly defined and carefully managed, (d) good development plans should be created and  executed, and (e) more programmers do not mean faster development. Fortunately, no software disasters occurred as a result of the rush to the moon, which is more a tribute to the ability of the individuals doing the work than to the quality of the tools they used.
Two things jumped out at me:
- "The lessons of this endeavor were the same learned by almost every other large system development team of the 1960s" – uh, isn't it sad that those same lessons had to be learned independently by so many groups?
- And today, 49 years later, we still haven't learned those lessons. Large software projects are routinely plagued with the same sort of problems we "learned" to avoid half a century ago.
Sadder still: I can think of a dozen or more software disasters NASA experienced since they "learned" these lessons.
These problems are not unique to NASA. Rather, they seem the very DNA of our profession.
Repeat after me: a) documentation is crucial, (b) verification must proceed through several levels, (c) requirements must be clearly defined and carefully managed, (d) good development plans should be created and executed, and (e) more programmers do not mean faster development.
We should blazon this on the entry way to our offices.
Feel free to email me with comments.
Back to Jack's blog index page.
Recent blog postings:
- 50 Years of Ham Radio - 2019 marks 50 years of ham radio for me.
- Medical Device Lawsuits - They're on the rise, and firmware is part of the problem.
- A retrospective on 2018 - My marketing data for 2018, including web traffic and TEM information.
- Remembering Circuit Theory - Electronics is fun, and reviewing a textbook is pretty interesting.
- R vs D - Too many of us conflate research and development
- Engineer or Scientist? - Which are you? John Q. Public has a hard time telling the difference.
- A New, Low-Tech, Use for Computers - I never would have imagined this use for computers.
- NASA's Lost Software Engineering Lessons - Lessons learned, lessons lost.
- The Cost of Firmware - A Scary Story! - A hallowean story to terrify.
- A Review of First Man, the Movie - The book was great. The movie? Nope.
- A Review of The Overstory - One of the most remarkable novels I've read in a long time.
- What I Learned About Successful Consulting - Lessons learned about successful consulting.
- Low Power Mischief - Ultra-low power systems are trickier to design than most realize.
- Thoughts on Firmware Seminars - Better Firmware Faster resonates with a lot of people.
- On Evil - The Internet has brought the worst out in many.
- My Toothbrush has Modes - What! A lousy toothbrush has a UI?
- Review of SUNBURST and LUMINARY: An Apollo Memoir - A good book about the LM's code.
- Fun With Transmission Lines - Generating a step with no electronics.
- On N-Version Programming - Can we improve reliability through redundancy? Maybe not.
- On USB v. Bench Scopes - USB scopes are nice, but I'll stick with bench models.