
Profile of Margaret Hamilton, programmer of the Apollo software - doppp
http://www.wired.com/2015/10/margaret-hamilton-nasa-apollo/
======
nickpsecurity
Many programmers talk about Ada Lovelace, who was certainly awesome, but
should be talking about Margaret Hamilton. Before anyone heard of Dijkstra's
work, Hamilton was straight up inventing everything from real, software
engineering to properly handling fault-tolerance and human interfaces. Here's
what she was doing (see Apollo Beginnings rather than USL):

[http://htius.com/Articles/r12ham.pdf](http://htius.com/Articles/r12ham.pdf)

Her Wikipedia page gives her due credit and shows just how much she and her
team pulled off:

[https://en.wikipedia.org/wiki/Margaret_Hamilton_%28scientist...](https://en.wikipedia.org/wiki/Margaret_Hamilton_%28scientist%29)

Also note the size of that printout of her program. Try to think about how
many people make one like that which doesn't fail in the field even when parts
of its environment and hardware are failing. Also while using low-level code
with little to no tool support on 60's era, embedded hardware rather than a
JVM, etc. Margaret Hamilton was the first in the field of high-assurance
programming that I've seen. A lot of firsts.

So, I give her credit where possible. The industry should even more as she
wasn't a theoretical programmer like Ada Lovelace: she engineered actual
software, co-invented many of the best practices for it, deployed them
successfully in production, and then made a tool that automated much of that
from requirement specs to correct code.

While programmers and industry ignore her, at least NASA gave her positive
mention as the founder of software engineering and ultra-reliable software
along with the biggest check they ever cut to an innovator:

[https://www.nasa.gov/home/hqnews/2003/sep/HQ_03281_Hamilton_...](https://www.nasa.gov/home/hqnews/2003/sep/HQ_03281_Hamilton_Honor.html)

Where would our systems and tools be if more attention was put into her
methods, even just principles, than informal use of C? ;)

~~~
vezzy-fnord
Another woman computer science first seldom celebrated is Kateryna Yushchenko,
who invented a high-level programming language with pointers in 1955, 3 years
before FORTRAN:
[https://en.wikipedia.org/wiki/Kateryna_Yushchenko_%28scienti...](https://en.wikipedia.org/wiki/Kateryna_Yushchenko_%28scientist%29)

Sadly, being behind the Iron Curtain was likely a primary reason for her
relegation to obscurity.

~~~
s_q_b
Meet USN Rear Admiral Grace Hopper:

[https://en.wikipedia.org/wiki/Grace_Hopper](https://en.wikipedia.org/wiki/Grace_Hopper)

Inventor of the compiler, early advocate of machine-independent computer
languages, creator of COBOL, originator of the verb _debugging_.

~~~
leoc
Not really the creator of COBOL, it seems
[http://cacm.acm.org/magazines/2015/9/191176-innovators-
assem...](http://cacm.acm.org/magazines/2015/9/191176-innovators-
assemble/fulltext) [A¢M paywall]:

> On page 117 Isaacson credits Hopper as "the technical lead in coordinating
> the creation of COBOL," a hugely important standard language for business
> programming that was defined jointly by several computer companies.
> Standards committee work is a difficult thing to dramatize, which is
> presumably why Isaacson gives COBOL no more than a passing mention, but as
> historian of technology Janet Abbate recently noted, his omission slights
> several women who, unlike Hopper, were on the technical committee in
> question. Among them is Jean Sammett, who made the largest single
> contribution to the design of COBOL. Sammet has stated that Hopper was "not
> the mother, creator, or developer of COBOL," an idea Hopper reportedly
> endorsed by calling herself the "grandmother of COBOL" rather than its
> creator.

> [...] Sammet has not been forgotten, as a fellow of the Computer History
> Museum and a winner of the IEEE Computer Pioneer Award, but sits on the
> wrong side of a growing chasm separating the handful of women chosen for
> public veneration from those whose names are known only to specialists.

> This is an example of what sociologist of science Robert K. Merton called
> the "Matthew Effect," the tendency for the most famous person involved in
> any collaborative project, however peripherally, to be remembered by the
> public as the key contributor. He named it after a passage in Matthew's
> Gospel, noting that "unto every one that hath shall be given, and he shall
> have abundance: but from him that hath not shall be taken away even that
> which he hath." Over time the famous become more famous, while the
> moderately well known are forgotten.

~~~
RogerL
There is essentially nothing about COBOL in Sammett's Wikipedia page.

edit: that is not disagreement with your point, but pointing out there may be
a deficiency in Wikipedia that needs correcting.

------
lumberjack
Only tangentially related but it seems to me that if you want to work on cool
software that does something novel and exciting it seems like it's better to
graduate with a degree in math or physics.

Also interesting if you visit her company's website:
[http://www.htius.com/](http://www.htius.com/)

It's a view into a software industry that is virtually never reported on in
the news, at least not on HN. The client list is impressive. It's not really
clear what they actually do? Seems to me like they maintain a developing
environment and sell support contracts for it?

~~~
TallGuyShort
>> if you want to work on cool software that does something novel and exciting
it seems like it's better to graduate with a degree in math or physics

Speaking more generally, you need domain knowledge outside of computer
science, so that you understand which applications to tackle and how to apply
the engineering knowledge in a specific vertical.

~~~
Swizec
I've been focusing mostly on software engineering for the past 60% of their
life (started at 9, am now 28). Last year I realized that even though I'm a
good engineer who knows many tools and so on, who wouldn't dare see everything
as a nail despite having a hammer. Despite all that, when you look at me from
the outside, from the perspective of someone who isn't an engineer, I am just
a very good hammerer.

I look at everything through the lense of software engineering. Because at the
end of the day, even though I have many different hammers, I'm still pretty
much just a hammerer. To make an actual thing, I need a domain expert.

And that's kinda frustrating when you think about it.

~~~
TallGuyShort
You need good hammering specialists, though. The trick is to recognize that's
who you are, and team up with domain experts you really click with. It just
really helps to be both if you want to be a lone leader who comes up with
visionary ideas.

------
Animats
She and Saydean Zeldin used to have a company called Higher Order Software. I
met them decades ago, when they were promoting that. They have an unusual
formalism which never caught on.

There was a lot of interest in formal techniques in the late 1970s and early
1980s, but the technology didn't go that way.

~~~
Torgo
Please talk about this more.

~~~
Animats
See this paper rejecting the technology for the Trident missile program.[1]
Also this harsh critique from Djkystra.[2] And this writeup on HN last
year.[3]

I encountered HOS back when I was doing proof of correctness work, and didn't
really understand how it got beyond very simple problems. But I thought, at
the time, that was my fault. In retrospect, it's an approach for a certain
class of control problems dominated by required relationships between certain
variables. That's what flight control systems are all about.

Control problems are typically expressed as a set of "laws", equations which
define what's supposed to be happening given the inputs and perhaps past
inputs. Some of these are equations, and others are constraints. Checking
those laws for contradictions and turning those laws into code is partially
automatable, and that's what HOS was trying to do.

HOS only seemed to work well with the founders driving it. Somehow, they were
never able to express clearly what they were doing. Sometimes that happens.
Norm Hardy, who came up with capability-based systems and created KeyKos, a
capability-based OS for IBM mainframes, had that problem. The system worked
great, but nobody understood what he was doing. He used to have an
"explainer", Susan Rajunas. In both cases, the startups went bust.

Trying to get people to understand a complex formal system is very hard.
Harder than developing one.

[1]
[http://www.dtic.mil/dtic/tr/fulltext/u2/a198753.pdf](http://www.dtic.mil/dtic/tr/fulltext/u2/a198753.pdf)
[2]
[https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/E...](https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD852.html)
[3]
[https://news.ycombinator.com/item?id=8736450](https://news.ycombinator.com/item?id=8736450)

~~~
xerophyte12932
> Trying to get people to understand a complex formal system is very hard.
> Harder than developing one.

Add another one to that list: Exactly how this complex system benefits people

------
danso
I knew Hamilton's achievements in the Apollo program were remarkable...but I
hadn't known that she had started while being as young as 24 -- _and_ being a
mother. That's just incredible. I can't even imagine going through school as a
father and being able to balance my time, never mind having to carry child.
Nevermind being a star programmer at MIT. And her husband was going through
law school at the time, which means not only did she not have a stay-at-home
husband to take over the parenting duties, she was the breadwinner.

------
hoorayimhelping
Excellent chapter from the documentary Moon Machines about the Apollo guidance
software (worth getting the whole thing on Amazon if you like this sort of
thing), told from the point of view of the people who built the machines,
rather than the astronauts.

[http://www.dailymotion.com/video/xxxiij_moon-
machines-2008-p...](http://www.dailymotion.com/video/xxxiij_moon-
machines-2008-part-3-the-navigation-computer_tech)

[http://www.amazon.com/Moon-Machines-Robert-
Seamans/dp/B0026I...](http://www.amazon.com/Moon-Machines-Robert-
Seamans/dp/B0026IQTR2)

------
davegauer
A fascinating read about the incredible capabilities of the Apollo software is
_Digital Apollo: Human and Machine in Spaceflight Paperback_ by David A.
Mindell.

Those craft were quite likely capable of a _lot_ more than they were ever
allowed to do by the astronauts - though I guess we'll never know!

~~~
TallGuyShort
Seconding the recommendation! I read it last winter and was the most enjoyable
/ interesting read I've had in years.

------
ourmandave
Is she a candidate for the $10 bill?

~~~
AnimalMuppet
And if not, why not?

~~~
codewritinfool
Agreed!

------
ghaff
From the article:

>Once the code was solid, it would be shipped off to a nearby Raytheon
facility where a group of women, expert seamstresses known to the Apollo
program as the “Little Old Ladies,” threaded copper wires through magnetic
rings (a wire going through a core was a 1; a wire going around the core was a
0). Forget about RAM or disk drives; on Apollo, memory was literally hardwired
and very nearly indestructible.

I was at a talk by Richard Battin, also of Draper on the Apollo program, a few
years back. One of the stories he told was of a number of the Apollo
astronauts visiting Raytheon (where the core memory was being "sewn") and the
general gist of the visit was "be really careful with your work or these nice
young boys could die."

~~~
alexsb92
In the "The Right Stuff" by Tom Wolfe, he mentions quite a few situations
where the Mercury astronauts would visit factories and facilities in charge
with building various components, and in all of these cases there was the same
gist of "be really careful with your work or these nice young boys could die."
So this practice existed from the very beginning of the American space
program.

I wonder if any of that still happens these days. Probably way less now when
American astronauts hitch a ride on the Soyuz.

~~~
RogerL
I worked a program in the early nineties. We all met the test pilots that
would fly the bird. It was abundantly clear (they made it clear) that lives
were at stake, and that they wouldn't step inside unless they trusted you and
your work. They had the unilateral right to declare the entire program 'no
go', and rightly so. This is formalized as a "flight readiness review", but of
course you meet the pilots before that. This was a Navy helicopter, not space,
I can't speak to what happens at NASA these days, but I can't imagine it's
much different.

------
oldmanjay
>why the gender inequality of the Mad Men era persists to this day

Well, that's demonstrably untrue, but the narrative, it must be pushed at all
costs.

~~~
jleader
"Demonstrably untrue"? Are you arguing that there's no more gender inequality
in software development?

------
dang
Also
[https://hn.algolia.com/?query=margaret%20hamilton&sort=byPop...](https://hn.algolia.com/?query=margaret%20hamilton&sort=byPopularity&prefix&page=0&dateRange=all&type=story).

~~~
kelvin0
Another of my favs:
[https://hn.algolia.com/?query=Jeri%20Ellsworth&sort=byPopula...](https://hn.algolia.com/?query=Jeri%20Ellsworth&sort=byPopularity&prefix&page=0&dateRange=all&type=story)

