From the article:

You coined the term “software engineering.” What was it called before and why did you invent the term?

MHH: It helps to know what it was like back then for those of us building the Apollo on-board flight software. During the early days of Apollo, software was treated like a stepchild; it was not taken as seriously as other engineering disciplines. Considered a mysterious “black box”, it was regarded by many as an art, not a science. To me it was both. Understanding the subtleties of developing real-time asynchronous flight software was left up to the flight software’s systems- software experts. Having this kind of responsibility resulted in our creating a “field”, since there was no school at the time to learn “software engineering”. This necessitated our creating methods, standards, rules and tools for developing the flight software. We were always looking for new ways to prevent errors. When answers could not be found, we had to invent them as we went along.

Many requirements for the flight software were “thrown over the wall” from mission application experts to software engineering experts. To some mission experts, software “magically” appeared within the on- board flight computer, integrated and ready to go. As time went on, what had begun originally as mission requirements for the flight software became more and more understood by everyone in the form of the more application-oriented parts of the flight software, itself, that realized the mission requirements; and the mission expertise moved on from mission experts to software engineering experts. Requirements engineers and software engineers necessarily became interchangeable, as did their life-cycle phases— suggesting that a system is a system, no matter from which discipline things had originated. From this perspective, system design issues became one and the same as software engineering design issues. Yet, the systems-software part of the flight software was in a world all of its own!

“What is the difference,” I asked, “between what they are doing and what we are doing?” Knowing this, and the lack of understanding by many of what it took to create real world software-based systems and the part our software played within these systems, I wanted to give our software “legitimacy” so that it (and those building it) would be given its due respect; and, as a result I began to call what we were doing “software engineering” to distinguish it from other kinds of engineering; yet, treat each type of engineering as part of the overall systems engineering process. When I first came up with the term, no one had heard of it before, at least in our world. It was an ongoing joke for a long time. They liked to kid me about my radical ideas. It was a memorable day when one of the most respected hardware gurus explained to everyone in a meeting that he agreed with me that the process of building software should also be considered an engineering discipline, just like with hardware. Not because of his acceptance of the new “term” per se, but because we had earned his and the acceptance of the others in the room as being in an engineering field in its own right.