I very much enjoyed reading your defense of the AGC. I too think it was a remarkable achievement. It would be fun to see how many of us today could reproduce it given the same hardware constraints. Few, I think.

Your "correction" of the first quote in Visseer's book reminded me of this story. I hope you enjoy it.

In mid July, 1975, I went to work for Powers Regulator, a maker of hospital-type pneumatic tube transfer systems. I had been hired as an electronic test technician. My job was to test and repair circuit boards hand assembled by the girls out back in the shop. Can you believe we actually repaired things in those days?

Over the next couple years I built many test fixtures. The most complex was controlled by a Texas Instruments 960B minicomputer -- the same computer that ran the pneumatic tube systems. I programmed it in assembly language. My test programs worked well, but were difficult to debug or modify. I'd fix one problem and later find I'd created one or two more. I was envious of the professional programmers on the other side of the building, and wanted to learn how they were able to write programs that were easy to understand, test, and modify. And I naively thought they could do that!

In September of 1978, Powers promoted me to "Scientific Programmer" and I joined the pros on the other side of the building. My job was to maintain and modify the code that controlled the pneumatic tube systems.

I spent my first month as a professional programmer trying to understand the system control code. It was immensely complex! To help me understand it, I made a call diagram that showed how all the three dozen (or so) modules interacted. It looked like a drawing of a bowl of spaghetti and meatballs. Module A would sometimes call module B, and it might or might not return to A. Module B would sometimes call module C and module C would sometimes call module A, but other times call module D, etc, etc. I learned later that "Spaghetti Code" was common.

At the end of that first month, I was ready to resign as a programmer, having convinced myself I didn't have the intellectual capacity to understand programs written by "professionals."

Right at this time, I somehow heard of the book Techniques of Program Structure and Design by Edward Yourdon (1976) and bought a copy. The book saved my career!

I still remember sitting at my desk in the computer room and reading it for the first time. I don't know what triggered it, but I soon had an epiphany. I closed the book and said out loud, "There's nothing wrong with me, this code is just crap!"

I followed Yourdon's advice and was soon able to write well structured programs that were easy to correct and modify -- even those written in assembly language.

Interestingly enough, Edsger Dijkstra thought the book was pretty much nothing more than "junk and trash" in his scathing published review. Well, at the time it was my GO TO (pun intended) book, and it now has a place of honor on my wall behind the glass in its own frame. And I still use GOTOs judiciously where appropriate. So there, Edsger.

A few years ago I wrote Yourdon and thanked him for saving my programming career. I couldn't resist teasing him about a statement he made in the book: "Unless you are very rich and eccentric, you will not enjoy the luxury of having a computer in your own home ..."

He graciously wrote back and acknowledged he'd been teased many times about that comment.

Thanks for the Muse, Jack. I always enjoy reading it.

The links to Apollo technical details in Embedded Muse #304 turned out to be very interesting - Amazon will be happy with me. Readers who want a quick technical intro to the the Lunar Module Digital Autopilot and don't have access to Eldon Hall's book might enjoy Dick Gran's article on the topic, which includes a download link for a 3 degree of freedom (3-DoF) Simulink model of the control system feeding a model of the LEM's inertial behavior:

  http://www.mathworks.com/company/newsletters/articles/fly-me-to-the-moon-then-and-now.html 

Dick was in the Grumman Guidance and Control group on a field assignment to the MIT Instrumentation Laboratory from 1963 to 1966.  

You had a nice write-up on Apollo Guidance Computer and mission. Yet, it was alarming you didn't once mention the woman behind its success: Margaret Hamilton. She and her team practically invented software engineering in a vacuum with many lasting techniques of high-reliability design. Then, seeing where the problems showed up, she invented the first, correct-by-construction tool to go from formalized requirements to semi-automatic design to automatic generation of code, tests, and traces. A NASA review, plus reading papers, showed it had serious usability issues due to constraints needed to pull that off plus performance problems.

Yet, here's a woman and team starting out in 1960 that invents the core of software engineering then implements high-assurance, systems engineering right after. She totally succeeded on former, saving Apollo mission during failure, with mixed results on latter. That's very remarkable and we probably owe Apollo success partly to her team and their methods. Wired points out she snuck the stuff in there because NASA mocked her belief that astronauts could make mistakes. (Lol.) Next time some fool mocks Apollo software tell them to look at the stack of source code Hamilton is holding up in Wikipedia picture. Then, ask if they've ever wrote that much code in constrained, unreliable environment in assembler without *a single failure* in production. I'm betting not. :)

Wired - Her Code Got Humans to the Moon
http://www.wired.com/2015/10/margaret-hamilton-nasa-apollo/

Margaret Hamilton, achievements, and picture of source
https://en.wikipedia.org/wiki/Margaret_Hamilton_%28scientist%29

Articles on her website (htius.com) about her methods
http://htius.com/Articles/articles.htm

Regarding her website, just ignore USL stuff to jump straight to "Universal Systems Language: Lessons from Apollo" focusing on "Apollo Beginnings" section and subsections on p2. It shows how they determined most root problems in systems and code then kept devising clever methods to prevent or catch them. Most stuff I read about in 2016 from CompSci is dealing with the same problems but with more usable specification languages. Dijkstra et al's published work of solved a *subset* of these *years later*. Talk about being ahead of the curve on software/system design and reliability.

The question of "is this maintainable" is one that should be on the mind of every developer every time they have their editor open. The hard part about doing as the title suggests is not the desire, will, or ability from those in technical leadership; it's often the ability to communicate the methods and goals of maintainability to the other members of the team in ways they don't just understand, but internalize.

I'm always surprised at the number of software developers who think the C or whatever they learned in college is all they really need to know, and the number people who fall into software development from other disciplines who think it's "easy" because they made it through an intro programming book and can hack together something that "works." Professional software developers, of course, understand that "working" code is just the tip of the iceberg, and things like code quality (and standards), exception management, proper source code management (SCM)[1][2], build systems, testing, documentation, and repeatability are the things which make software development into a discipline[3]. Getting stuff to "work" and then leaving it there is the equivalent of nailing 2x4's together in your garage with no plan. Sometimes it gets you to the goal, but it can hardly be called "engineering."

Alan.

[1] To anyone who has recently made a commit message reading "changes," "bug fixes," "integrated dev branch," or otherwise used non-descriptive, improper language to describe their changes, this doesn't count as engineering. Work doesn't get to stop when it's no longer fun.

[2] As a user of the distributed SCM, I've become increasingly convinced this is the right way to do software development. There are so many dimensions of distributed SCM that provide a positive impact, but the largest of which is the idea of sending a pull request to your team leader, rather than every junior engineer pushing directly into the master repository. We wouldn't accept changes without review in other engineering disciplines, why should it be done in software?

[3] There is no shortage of debate around whether software engineering is really an engineering discipline. Flame wars aside, Software development can certainly be done with discipline, but often is not.