Jack Ganssle, Editor of The Embedded Muse Jack Ganssle's Blog
 RSS Feed This is Jack's outlet for thoughts about designing and programming embedded systems. It's a complement to my bi-weekly newsletter The Embedded Muse. Contact me at jack@ganssle.com. I'm an old-timer engineer who still finds the field endlessly fascinating (bio).

For novel ideas about building embedded systems (both hardware and firmware), join the 40,000+ engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. Click here to subscribe.

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 it 143. 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 [53] 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.

Sad.

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. And here are some guidelines.

Feel free to email me with comments.

Back to Jack's blog index page.

If you'd like to post a comment without logging in, click in the "Name" box under "Or sign up with Disqus" and click on "I'd rather post as a guest."

Recent blog postings: