JULIAN SIMIONI: All right. Everyone can hear me well now?
They've turned it off. Everything's good.
All right. It says 3:50 on the little clock
here which means it's time for me to go.
So, hi everyone. I'm Julian. This is my first
RailsConf. It's great to be here. We are not
gonna talk about Rails at all. We're gonna talk
about space. This is one of my favorite pictures
ever, right. It's the, the Earth rise picture from
Apollo 8.
And my whole life, I've just loved space. From
when I was a little kid, it just inspired
me so much. I know it inspires tons of
other people. I know, I got into a technical
field because, as a kid, I loved space. Raise
your hand if you think it's the same thing
for you. I know I've talked to so many
people where that's the case. Awesome.
And I mean, just, space is really cool, right.
There is, just, you know, everything about astronomy or
manned space explorations is just really, really awesome and
inspiring. And there's one thing, above all else, that
inspires people just so much, and that, of course,
is the Apollo program.
Landing on the moon is, maybe, the greatest thing
that humans have ever done. And, and, you know,
people will talk about awesome rockets, right. Like, the
Saturn 5. It generates seven and a half million
pounds of thrust on takeoff. That's. That's a lot.
Or they'll talk about, you know, astronauts who, who
trained for years, and, you know, were brave and
took insane risks that, you know, most of us
can't even comprehend. Or they'll talk about mathematicians and
awesome things they did for, like, the guidance equations
and stuff to get people to the moon safely
and back.
And then they'll say things, like, oh, yeah, we,
we landed on the moon with, you know, less
computing power in a wrist watch, or something. And
as a software developer, you know, that makes me
sad. You know, for a long time, I didn't
really think that there was anything in the Apollo
program to inspire us software developers. And, fortunately, it
turns out, that is not at all the case.
So this is the Apollo guidance computer. To give
you a sense of the scale, the little display
is, like, a little bit bigger than your hand.
I think it's like, nine by nine inches. So
this thing was built to take people to the
moon. And it is awesome in ways you might
not expect.
So it only had two kilobytes of RAM, I
think. Not very much. It was really, really, really
slow. I did some back-of-the-envelope calculations, and it turns
out all of the computation done on all of
the Apollo missions, ever, could be done by my
little laptop over there in under a second.
But, my laptop may or may not make it
through this talk. The Apollo guidance computer never hit
an unknown bug, in thousands of hours of time
in space. It never failed, despite the fact that
space is pretty hostile, right. There's, there's like gamma
rays. Anything metallic that floats around will, will find
the one place where it can short things out
and, and cause lots of problems.
And so this thing is pretty amazing. It worked
really, really well. But what's even more amazing is
that it was built at a time when we
didn't know much about making software. They started working
on it in 1961. And they finished in 1968.
So to put that into perspective, in 1965, the
MIT instrumentation lab, that's the department of MIT that
was building this thing, they got this new computer.
It's called an IBM system 360. Anyone heard of
that before? It's one of the more famous computers
in the history of computing.
So there's one particularly famous person that worked on
it. And anyone know who I'm talking about? Anyone
have an idea? Come on, you all know. Fred
Brooks, right. And he, he wrote this book. What
was the book called? Anyone? The Mythical Man Month.
Yeah. So when did he write that book? Not
until 1975. And by then, you know, we had
been gone from the moon for many, many years.
So think about what that means, right. The, the
software developers writing code for the Apollo Guidance Computer
were learning the same things as Fred Brooks at
the same time, right. So if you're a manager
at a, you know, you have some software developers
working under you, and your boss comes to you
and says hey, you know, your projects a little
bit late. I'm gonna, you know, give you some
more developers to hopefully speed it up, you say,
OK. Whereas today you might say, no. Read The
Mythical Man Month, and you know that that won't
work.
So, another thing. The word software was first used
in 1950. It was used in, like, a research
paper. And there's some back story here. It's pretty
important. We're gonna do a little aside.
So, the first computers in, in the, you know,
20s, 30s, 40s. They were built by men. Like,
predominantly, overwhelmingly men. And, and they would build these
computers, and the computers did one thing, right. You
would build a computer to, you know, calculate the
Fibonacci sequence or something, and if you wanted a
computer to, to calculate prime numbers, like, you built
another computer, or you took the computer you had
and, and modified it really heavily, right. And over
time, you know, computers got a little bit better
and, and then they could sort of be configured,
right. They could, you could like, flip some switches
and set some bits and then the computers would
do different things and, and, and the men building
these computers that, they hated this task, right. They
thought it was boring and that it was easy
and that it wasn't very interesting at all. So
they hired a bunch of women to do all
these things, right. And only later, like, as time
goes on, did they figure out that, that this
task of configuring the computer that, that the men
had built was actually the entire field of software
development, and that it was actually really, really hard
and challenging and it was a field onto itself.
And only then did, did men start coming in
and start saying, hey, I would like to do
this. During the Apollo program, one of the managers
of, of one of the software teams, when he
was assigned to that team, his wife was told
by him, hey, honey, don't tell any of our
friends that I manage a software team. Cause it
wasn't, it wasn't cool for a guy to write
software, yet, in the, in the 60s. It was,
it was getting there.
So, it's kind of interesting, right. So here's my
takeaway from that. If you're a woman and you're
writing some software, and you're maybe thinking, hey, you
know, maybe I'm not cut out for this or,
or some other people are saying things that say
that I shouldn't be here. Don't listen to them.
That's bull shit. You're grandma was writing code. And,
and she did a damn fine job. So don't
worry about that.
And if you're a guy, a man, or woman
I guess, and you're thinking or saying or writing
things like, you know, women shouldn't be here. They're
not as good at writing code as men. Stop.
Stop saying those things. That is all bull shit.
It, that does not stand up to the history
of computing. So. Just a little aside there.
Anyways, OK. We're talking about the Apollo Guidance Computer,
and things that people learned from that. So, what,
let me ask you guys a question. How many
of you have built some sort of web app,
maybe a Rails app or something, and you depend
on someone else to service. Right, an API or
something like that. Someone, something that another team at
your company built or something external, right. And what
happened to your site the first time that thing
went down? Yeah, I heard a very sad noise
of something breaking.
Yeah. Exactly. Your pager goes off. Although maybe in
the 60s, I don't think they even had pagers.
So what did you do after awhile, right? You,
you, the first time you fixed that one thing,
right, you fixed it so that that particular thing
happens again, you know, it'll be OK. And then
something else happens and something else happens, and hopefully
after awhile you, your, your system is smart enough
that anything that this, this other system throws at
you, something you've never even seen before, you know,
it doesn't matter. You'll keep running just fine.
And so the same thing happened during the Apollo
11 landing. So this is the Lunar module. So,
so picture, this is the most critical moment of
the entire Apollo space program, right. Neil Armstrong and
Buzz Aldrin are, are in this little thing. They're
heading down towards the surface of the moon. And
this, the last ten minutes of this are by
far the most, absolutely the most critical and, and
high intensity part of the entire, of the entire
mission.
Neil Armstrong said that those last couple of minutes,
on a difficulty scale of one to ten were
a thirteen, right. And he's, he's a pretty good
pilot. So that means a lot.
So, so, so they're cruising down towards, towards the
surface. They're, they're busy. They're in the zone. All
of the sudden, on their dashboard, you know, a
big light comes on. The master alarm. Everything is
wrong. And their computer is, is giving them this
error, this, like, twelve-oh-one error.
And, you know, the astronauts are distracted and mission
control, they're freaking out. They're trying to figure out
what this is. You know, what does this mean?
One of the MIT engineers in, in mission control
had, very wisely, made a little cheat sheet of
every error code that the computer could throw up.
Very, very smart.
And he, you know, he, he looks up, OK,
twelve-oh-one. What does it say? It says, if, if
nothing else seems wrong, you know, you're good to
go for the landing, and he actually was too
scared to form words, so when he was asked,
you know, are we good to go? He just
sort of like, made a thumbs up. And then
he was awarded a medal from the President of
the United States for his, for his decision to,
to not abort the moon landing.
So what happened? What was this master alarm that
scared the crap out of everyone for actually no
reason? So, today we're pretty lucky with our computers,
right. If you, if you write some code that
does an infinite loop or something, your computer will
probably handle it just fine, right. You have to,
you have to do something pretty crazy to crash
your computer.
The very idea that multiple programs could even be
running on a computer was new in the 90s,
1960s. They, they didn't have words like scheduling or
tasks or processes like we have today. They called
it, they called it, like, like, timesharing, right. And,
and up until the Apollo, Apollo guidance computer had
been built, they didn't do anything sophisticated like, like
have priorities assigned to different tasks. They just said,
anything that wants to run, we'll let it run
for a little while, and then we'll run something
else.
And a lot of engineers thought that this approach
was safe, because it was more predictable, and it
was easier to reason about. But it has a
downside, in that you, with something like priority-based scheduling,
you can, you can figure out what are the
most important things that need to be running, right.
The program to fire the thrusters should probably run
exactly when it wants. The program to update the
display for the astronauts, if it's a couple milliseconds
late, I think they'll be OK.
And so this was a brand new approach for
the Apollo program, or for computing in general. So,
the takeaway here is handle failure gracefully. Just do
a little bit of actual work so that something
unexpected can come up and you'll handle it just
fine.
Step two of that, by the way, is if
you get to the point where you can handle
an unknown failure gracefully, don't throw, like a master
caution alarm and raise a ruckus when, you know,
you're actually handling everything great.
OK. So, who would have ever thought that in
a RailsConf, talking about testing would be, would be
weird? But I have an entire segment about testing.
Thanks DHH for that.
So, there were lives on the line. They're traveling
into space, which is pretty difficult. There was a
ton of testing for the software, for the software
for the Apollo Guidance Computer. They, they had unit
tests. They actually even called them unit tests but
with, with quotes, cause it was like a brand
new word for them.
But the, the engineers didn't really talk much about
their unit tests. They said they were OK, but
they didn't, like, rant and rave about them. And
I have a theory as to why that is,
and that's because most of the code for the
Apollo Guidance Computer was, was, was like functional code.
Not in like the programming sense but al, also
in the mathematical sense on which it's based. Right?
You have, you have code for guidance equations. And
furthermore you have mathematicians writing them.
The idea of a computer science degree did not
exist in the 1960s. I think the last, the
first computer science degree was actually awarded, like, in
the late 60s. So no one writing these computers
was trained as a software programmer, right, or as
a computer scientist. They were trained as mathematicians. And
they were writing code to implement mathematical equations. And,
as you can imagine, eventually they'll get it right.
So, what they do talk really, really highly about
is their, their integration tests. And now, I have
no idea. Should we call these system tests or
some other kind of tests? But anyways.
In 1972, they published a retrospective on basically the
entire software development effort, and they said things. They,
they talked specifically about things that plagued the software
development effort throughout the entire program. And they listed
two things, and they're both really interesting. I have
a link to it at the end of my
slide, so definitely check it out when you get
a chance.
The first thing that they just could not get
right was estimating schedules. And we don't get that
right today so, great. We've made a lot of
progress there. One cool thing they did actually was
they, they cataloged a bunch of ways in which
they can go wrong, right. Like if you have,
if you have two projects competing, or two projects
that are running in parallel, and one of them
is gonna take longer, and you make the one
that is not gonna take as long happen even
faster, you haven't actually made your whole project progress
any faster, right. Just to give an example.
The other thing they talked about, that plagued their
whole project, was getting up to date specs and
requirements and information about different systems. The Apollo program,
you know, was in a rush throughout its entire
development. Everything, every part of every system in the
space craft was constantly changing. And getting up to
date information about these other things is hard, right.
You have to go out and talk to every
team, and if they don't happen to tell you
that something's changing, you might not know.
Again, they didn't come up with a great way
to solve this, and again we still struggle with
this today. I think communication is the hardest part
of software development. But they did find out a
great way to figure out if you have it
wrong. And that's to write integration tests, where you
take everything together, right. Every part of your system,
and you test the hell out of it and
see what breaks.
And, and, and, so. What happens is, there's a
really interesting thing where your unit tests with test
your own code, and then you have integration tests,
which are also code. But they're not there so
much, they're not there so much to test your
code as they are to test your communication. So
to put it another way, if you. How do
I put this? Let's see.
If you, if your integration tests are failing, what
it means, not necessarily that you wrote bad code,
but you wrote great code that does the wrong
thing, right. So, so that's the takeaway there.
Another great thing they did that we don't do
today, is they tested what they call the off
nominal cases, which is just an awesome word, right.
We don't use nominal nearly enough anymore.
So, so. They said for every single, for every
one test they had that tested like the normal
case of things going right during a mission, they
had a hundred that tested things going wrong.
So how many of you guys have a test
in your Rails app, something like, if a user
logs in with the right username and the right
password, they get logged in, right. I, I do.
Right. A lot of hands go up. How many
of you guys have a test where if someone
puts in the right username and the wrong password,
they don't get logged in, right. Fewer hands go
up.
I didn't have that test until I was making
this talk. So I mean, there's so many different
tests for things going wrong that, that we don't
write today, I think. Anything from, you know, security
related or, or like, checking of all sorts of,
you know, inputs and stuff like that. But the
Apollo Guidance Computer team got it right, and there
were all sorts of cases during the Apollo program
where, where something went a little bit wrong and,
and something unexpected happened, and, and like Guidance Computer,
because they had done all these off nominal tests,
came out just fine.
So let's talk about their teams.
In 1961 when, when the instrument lab signed the
contract to deliver the Apollo Guidance Computer, that contract
didn't mention software at all. It said, you just
have to give us this, this box, with a
computer in it that can take men to the
moon.
And, so they didn't know if it was just
gonna be, you know, just a bunch of hardware
and it did this one thing and that's all
it needed or if it was gonna be like
a, you know, a fully programmable computer like it
turned out to be.
They, they didn't know, in 1961, what a space
craft that goes to the moon would look like
at all. They didn't know, you know, would it
be one giant ship that goes all the way
to the moon and then comes all the way
back? Would it be several little ships that are
combined together? Would they build two rockets and have
them meet up in space and then go from
there? Would they build one giant rocket? No one
knew.
No one knew if, even in principle, it would
be possible to navigate to the moon, right. They
didn't have the math to, to prove that you
could go to the moon. And no one knew,
even given math that can help you navigate to
the moon, if a computer could be built to
do it.
So there were, in these early days, there were,
you know, no deadlines. No managers. No requirements. Very
little communication with, with other teams. And what that
means is they were free to experiment and, and
figure things out, right.
A couple years later, OK. Now they know, we're
gonna go to the moon. One giant rocket. Two
little space crafts. One is just for landing on
the moon. We have figured out that, just like
at sea, you can use a sextant and measure
the angles between, like, stars and part of the
moon or part of the Earth and figure out
exactly where you are. And now we know what
the math looks like to take those, those navigation
measurements and plug them into a computer, which we
now know how to build, and we know it
can fit in a space craft and it can
take you to the moon.
So now there's four hundred software developers in the
Apollo Guidance Computer project. And now there's, there's lots
of managers. There's lots of deadlines. There's lots of
requirements. There's lots of documentation. So what happened is
they built, they had teams that were the right
shape and size for what they were trying to
accomplish, right.
If, if you were talking to someone who is
founding a startup, it's brand new, and they said
they had four hundred employees, you might be a
little worried. Likewise, if, if you were talking to
a programmer that happened to work for your bank,
and he said, we have a team of, of
twenty and we don't really have any requirements for,
you know, security or anything like that, you'd probably
find another bank.
So, so teams have to be the right shape
and size for what they want to accomplish. Another,
a corollary to that is switching between those team
sizes will be difficult and, at any given time,
there will be people unhappy with how your current
team is shaped. So NASA and the other contractors
building the Apollo space craft did not like that
there were these, these rogue engineers over at MIT
just fooling around doing whatever they wanted, you know,
and then that they were gonna have to somehow
deliver a guidance computer.
Likewise, as the team grew, a lot of the
smartest engineers, they left the, the guidance project once,
especially once Apollo 8 had gone to the moon,
right. A lot of the engineers said, OK. We've
done it. You know, a couple years ago we
had this cool challenge, and now we've figured it
out. Onto the next thing.
But the, the mission to the moon was successful,
right. The goal was accomplished. We had landed on
the moon before 1970. So the team was always
the right size.
All right, what's next. Let's talk a little bit
about working with users. Except, in this case, it's
actually working with astronauts. So, who's seen The Right
Stuff or read the book? Right, they're both great.
OK, lots of you.
How did they describe astronauts? Anyone? What's that? Reckless,
OK. Cowboys. Yes. There's a lot of scenes of
them riding horses around and stuff. They were arrogant.
They were extremely talented. They were hard to work
with. They're just like software developers.
So, just like any other user, astronauts don't know
what they want, right. As one of the most
important things you can, you can learn about working
with, with your users is they won't tell you
what they actually want. There's a great example of
this.
So the Apollo Guidance Computer was not just a
guidance computer. It was also an autopilot. It could
take you from Earth orbit to, you know, a
couple feet above the lunar surface, and it could
take you from the lunar surface all the way
back to Earth.
So, so the, the engineers at MIT, you know,
would talk to the astronauts, and they said, hey,
hey astronauts. You know, you know how, at the
end of your mission you have this, this re-entry
process and, and it's, it's pretty dangerous, right. If
you, if you're coming in too steep you can
burn up. If you don't come in steep enough
you can ricochet out into space and, and you'll
never come back. But, but we know we can
write an autopilot that will do this for you
automatically. You just have to press a couple buttons
and we'll get you right through every time.
And the astronauts said no. Do not do that.
You will be wasting your time. We are astronauts
and we are trained to do these hard things,
like, like do a manual re-entry. And astronauts, by
the way, were very distrustful of all automation. Partially
for good reason.
In the, in the 50s and 60s, a lot
of early flight tests with, especially analogue computers flying
aircraft had gone, had gone wrong. And a lot
of their friends had died. But on the other
hand, also, astronauts, you know, are super macho, right.
They don't like the idea of a computer taking
away something that, you know, they use to show
their skills.
So the astronauts said no. Don't even bother building
this, building this re-entry program, cause we'll never use
it. So the engineers built it anyways. And then
it was used on every single mission.
It turns out that when you've been in a
box in space with no showers and you're eating,
like, frozen, like, dehydrated food for like, up to
a week, and then there's a button you can
press so that you just have to sit back
and relax, and like four minutes later you're in,
you know, the warm air of the Pacific ocean
or something like that, you're gonna press those buttons
every single time, instead of doing one more hard
thing just to get home, when you've already done
everything you needed to do. So your users don't
know what they want.
Now let's talk about interfaces. Let's imagine you've built
this computer that can go to the moon, and
you've got your astronauts ready to go to the
moon, how do they talk to each other? Keep
in mind, this is the 60s. The field of
human computer action, human computer interaction isn't invented until
1980.
You can't use a CRT screen, because they're too
heavy. You can't use an LCD screen, because they
haven't been invented yet, either. And you can't actually
use any type of screen at all. It turns
out the Apollo Guidance Computer doesn't have the power
for anything like that. So you can use, you
know, little seven segment LEDs and you can use,
like, dials and stuff like that.
So what do you build that astronauts can use?
It has to be powerful, right. It can't just
be one button that says take me to the
moon and maybe another button that says take me
back, right. There's a little bit more going on.
And it has to be something that astronauts in
space suits can, can deal with, right. So I
don't think an iPhone would have worked even if
they had it. It has to be something that
you can operate very quickly, right. There's a little
bit of time pressure when you're moving at, you
know, five miles per second.
So I want to show you what they came
up with, and it's, it's this thing. And this
is not a very pretty picture, but it's here
just as an assurance, because I have a live
demo of it actually working. So this is the
display and keyboard unit. So we're gonna switch over
here.
So, some very smart people who are not me
have used ASM and taken an emulator running actually
Apollo Guidance Computer code. We have all the code,
by the way, and you can take a look
at it online. And they build an actual, functional
interface in your web browser to the guidance computer,
and I'm gonna show you guys how it works.
And I'm gonna see what you guys think.
So, so, you can see here, this thing on
the, on the left pretty much is the actual
interface. And then this stuff on the right is
just for running the, like the emulation. This sort
of represents like the, the simulated environment. They didn't
get this thing.
So, so what do we have here? We've got
a bunch of lights for, you know, warnings and,
and status and stuff like that. We've got just
a couple little bits of display down here. And
then we've got just a couple buttons. So, so
let me give you an example of how this
works.
So, what you can do, is you hit, you
pick a verb and then you pick a noun.
So a verb is something like, show me some
data. So that's verb zero-six. And then a noun
is something like, basically the current system up time
is noun sixty-five. And you hit enter. And it
shows you. You don't get any decimal points. So
you have. And you don't get any labels.
So you have to know what these mean. So
I'll, I'll tell you. So this means, this computer's
been running for one hour, thirty-one minutes and forty-nine
point eight eight seconds. OK, let's try something else.
Let's hit another verb. That's verb one-six. So that's
similar to verb six, except what it means is
show me some data and then keep updating it.
And then we'll do noun sixty-five again.
So now, again, one hour thirty-two minutes, and the
number of seconds are going up, and you can
see there's some activity.
So can anyone think of anything that maybe we
use every single day, some of us, at least,
that lets you take verbs and nouns and combine
them in all sorts of interesting and powerful ways?
Anyone?
AUDIENCE: Language.
J.S.: L- well. All right. Someone over there is
a smart ass. A computer program that we use
every single day with verbs and nouns.
AUDIENCE: HTTP.
J.S.: HTTP is a good one, but no. I
was thinking of VIM. VIM. Let's hear it for
VIM. Yes. Exactly.
I would love to, I would love to find
out that, that the interface in VI was influenced
by the Apollo Guidance Computer. I don't think it
was. If someone happens to know, please let me
know. That would be awesome.
But a funny thing, by the way, is that
this interface was, was intended to be temporary. All
the, all the engineers said, well, we don't really
know what to build. But we'll build this thing
with these verbs and nouns and it's kind of
clever and, and we'll use that until we build
something better. And, of course, we now know, like,
if you want something to stick around forever, just
say it's temporary.
But it's cool that the astronauts were, actually became
very adept at this, and it actually functioned really
well. And the fact that we still use, you
know, something similar in VIM today, like. Raise your
hand if you use VIM as your primary editor
for all the code you write? Exactly. It's maybe
twenty-five percent of the people in the room.
So I just think that's really, really cool. Let's
see. What else have I got for you? We're
gonna go back to the slides here, but just
to say I'm Julian Simioni. I work at 42Floors.
You can Tweet at me there. I am a
pilot in real life, and it's really fun. Again,
another thing I was inspired to do by the
space program. And I would love to take some
questions.
OK guys. Thank you so much.