 Turn it up, everything's good. All right, it says 350 in the little clock here, which means it's time for me to go. So hi, everyone, I'm Julian. This is my first real conference, great to be here. We're not going to talk about rails at all. We're going to talk about space. This is one of my favorite pictures ever, right? It's the Earthrise picture from Apollo 8. And my whole life, I've just loved space. 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 love space. Raise your hand if you think it's the same thing for you. I know I've talked to so many people where it's the case. Awesome. And I mean, just space is really cool, right? There's just everything about astronomy or manned space exploration 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 people will talk about awesome rockets, right? Like the Saturn V. It generates 7 and 1 half million pounds of thrust on takeoff. That's a lot. Or they'll talk about astronauts who trained for years and were brave and took insane risks that most of us can't even comprehend. Or they'll talk about mathematicians and awesome things they did for the guidance equations and stuff to get people to the Moon safely and back. And then they'll say things like, oh, yeah. We landed on the Moon with less computing power than in a wristwatch or something. And as a software developer, that makes me sad. For a long time, I didn't really think that there was anything in the Apollo program to inspire our 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 a little bit bigger than your hand. I think it's like 9 by 9 inches. So this thing was built to take people to the Moon. And it is awesome in ways you might not expect. So I only had 2 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 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 and space. It never failed. Despite the fact that space is pretty hostile, right? There's gamma rays. Anything metallic that floats around will find the one place where it can short things out 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, I know you all know. Fred Brooks, right? And he wrote this book. What was the book called? Anyone? The Mythical Man Month. So when did he write that book? Not until 1975. And by then, we had been gone from the moon for many, many years. So think about what that means. The software developers writing code for the Apollo Guidance Computer were learning the same things as Fred Brooks at the same time. So if you're a manager, you have some software developers working on to you, and your boss comes to you and says, hey, your project's a little bit late. I'm going to 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 our research paper. And there's some backstory here. So it's pretty important. We'll go on a little aside. So the first computers in the 20s, 30s, 40s, they were built by men, like predominantly, overwhelmingly men. And they built these computers. And the computers did one thing. You would build a computer to calculate the Fibonacci sequence or something. And if you wanted a computer to calculate prime numbers, you built another computer, or you took the computer you had and modified it really heavily. And over time, computers got a little bit better, and then they could be configured. You could flip some switches and set some bits, and then the computers would do different things. And the men building these computers, they hated this task. 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. And only later, as time goes on, did they figure out that this task of configuring the computer 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 alone to itself. And only then did men start coming in and start saying, hey, I would like to do this. During the Apollo program, one of the managers 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, because it wasn't cool for a guy to write software yet in the 60s. 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, maybe I'm not cut out for this or some other people are saying things that say that I shouldn't be here, don't listen to them. That's bullshit. Your grandma was writing code. And she did a damn fine job. So don't worry about that. And if you're a guy, a man or a woman, I guess, and you're thinking or saying or writing things like women shouldn't be here. They're not as good at writing code as men, stop. Stop saying those things. That is all bullshit. It does not stand up to the history of computing. So it's a little aside there. Anyways, OK, we were talking about the Apollo Guidance Computer and things that people learn from that. So 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's service, an API or something like that? Someone, another team 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 a while? The first time you fixed that one thing. You fixed it so that that particular thing happens again, you know, you'll it'll be OK. And then something else happens and something else happens, and hopefully after a while your system is smart enough that anything that this other system throws at you, something you've never even seen before, 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 picture, this is the most critical moment of the entire Apollo space program, right? Neil Armstrong and Buzz Aldrin are in this little thing. They're heading down towards the surface of the moon. And the last 10 minutes of this are by far the most, absolutely the most critical and high-intensity part of the entire mission. Neil Armstrong said that those last couple minutes on a difficulty scale of 1 to 10 were 13, right? And he's a pretty good pilot, so that means a lot. So they're cruising down towards the surface. They're busy. They're in the zone. All of a sudden on their dashboard, big light comes on, the master alarm, everything is wrong, and their computer is giving them this error, this like 1201 error. And the astronauts are distracted in 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 mission control had very wisely made a little cheat sheet of every error code that the computer could throw out. Very, very smart. And he looks up, OK, 1201, what does it say? It says, if nothing else seems wrong, you're good to go for the landing. And he actually was too scared to form words. So when he was asked, are we good to go, he just like made a thumbs up. And then he was awarded a medal from the President of the United States for his decision 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 write some code that does an infinite loop or something, your computer will probably handle it just fine, right? 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 1960s. They didn't have words like scheduling or tasks or processes like we have today. They called it time sharing, right? And up until the Apollo guidance computer had been built, they didn't do anything sophisticated like have priorities assigned to different tasks. They just said anything that wants to run will 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, right? It was easier to reason about. But it has a downside in that with something like priority-based scheduling, 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 is 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 extra 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're actually handling everything great. OK, so who would have ever thought that in a Rails conf, talking about testing would be weird. But I have an entire segment about testing. Thanks, DHH, for that. So there are lives on the line. They're traveling into space, which is pretty difficult. There was a ton of testing for the software for the Apollo guidance computer. They had unit tests. They actually even called them unit tests, but with quotes, because it was a brand new word for them. But the engineers didn't really talk much about the unit tests. They said they were OK, but they didn't 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 functional code, not in the programming sense, but also in the mathematical sense in which it's based. 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 first computer science degree was actually awarded in the late 60s. So no one writing these computers was trained as a software programmer 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 integration tests. And now I have no idea. I should be called 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 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 cataloged a bunch of different ways in which they can go wrong. Like if you have two projects competing or two projects that are running in parallel, and one of them is going to take longer. And you make the one that is not going to 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 was in a rush throughout its entire development. Every part of every system in the spacecraft 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. You take everything together, right? Every part of your system. And you test the hell out of it and see what freaks. So what happens is a really interesting thing where your unit tests will test your own code. And then you'll have integration tests, which are also code. But they're not there so much to test your code. As they are to test your communication. So to put it another way, 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 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. We don't use nominal nearly enough anymore. So they said for every one test they had that tested like the normal case. If things are going right during a mission, they had 100 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 that they get logged in, right? 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? A few 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 we don't write today, I think. Anything from security related or checking of all sorts of 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 something went a little bit wrong and something unexpected happened in the 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 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 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 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 fully programmable computer like it turned out to be. They didn't know in 1961 what a spacecraft that goes to the moon would look like at all. They didn't 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. They didn't have the math 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 no deadlines, no managers, no requirements, very little communication with other teams. And what that means is they were free to experiment and figure things out, right? A couple years later, okay, now they know we're gonna go to the moon, one giant rocket, two little spacecraft, 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 navigation measurements and plug them into a computer, which we now know how to build and we know it can fit in a spacecraft and it can take you to the moon. So now there's 400 software developers in the Apollo guidance computer project. And now 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 had teams that were the right shape and size for what they were trying to accomplish, right? If you were talking to someone who was founding a startup, it was brand new, and they said they had 400 employees, you might be a little worried. Likewise, if you were talking to a programmer that happened to work for your bank and he said we have a team of 20 and we don't really have any requirements for security or anything like that, you'd probably find another bank. So teams have to be right shape and size for what they want to accomplish. Another, a correlation 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 spacecraft did not like that there were these rogue engineers over at MIT just fooling around doing whatever they wanted, and then that they were gonna somehow have to deliver a guidance computer. Likewise, as the team grew, a lot of the smartest engineers, they left the guidance project once, especially once Apollo 8 had gone to the moon. A lot of the engineers said, okay, we've done it. A couple of years ago, we had this cool challenge and now we figured it out onto the next thing. But the mission to the moon was successful. The goal was accomplished. We landed on the moon before 1970. So the team was always the right size. 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. Okay, lots of you. How did they describe astronauts? Anyone? What's that? Reckless. Reckless, okay. Cowboys. Cowboys, yes. There was a lot of scenes of them riding horses around and stuff. Let's see. They were arrogant. They were extremely talented. They were hard to work with. They're just like software developers. So just like any other users, astronauts don't know what they want. One of the most important things you can learn about working 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 a couple feet above the lunar surface and it could take you from the lunar surface all the way back to Earth. So the engineers at MIT would talk to the astronauts and they said, hey, astronauts, you know how at the end of your mission you have this re-entry process and it's pretty dangerous, right? 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 you'll never come back. But we know we can write an autopilot that will do this for you automatically. You just have to press a couple of buttons and we'll get you right through every time. And the astronaut 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 do a manual re-entry. And astronauts, by the way, were very distrustful of all automation, partially for good reason. In the 50s and 60s, a lot of early flight tests with especially analog computers flying, aircraft had gone wrong and a lot of their friends had died. But on the other hand, also, astronauts are super macho, right? They don't like the idea of a computer taking away something that they use to show their skills. So the astronaut said, no, don't even bother building this re-entry program because 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 frozen, dehydrated food for up to a week, and then there's a button you can press so that you just have to sit back and relax and four minutes later you're in 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 need to do. So your users don't know what they want. And 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 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 little seven segment LEDs and you can use 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. There's a little bit more going on. And it has to be something that astronauts in space suits 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 it, you know, five miles per second. So I wanna show you what they came up with and it's this thing. And this is not a very pretty picture but it's here just as insurance 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 actual Apollo guidance computer code. We have all the code by the way and you can take a look at it online. And they've built 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 you can see here this thing on the left pretty much is the actual interface. And then this stuff on the right is just for running the emulation. This sort of represents the simulated environment. They didn't get this thing. So what do we have here? We've got a bunch of lights for warnings 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 let me give you an example of how this works. So what you can do is 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 uptime is noun 65. You hit enter. And it shows you, you don't get any decimal points. So you don't get any labels. So you have to know what these mean. So I'll tell you. So this means this computer has been running for one hour, 31 minutes and 49.88 seconds. Okay, 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 65 again. So now again, one hour, 32 minutes and the number of seconds are going up and you can see this 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 powerful ways? Anyone? Well, all right. Someone over there is a smart ass. A computer program that we use every single day with verbs and nouns. 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 find out 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 intended to be temporary. 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 we'll use that until we build something better. And of course, we now know 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 functions really well. And the fact that we still use 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 25% 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 Simione. I work at 42 Floors. 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. Okay guys, thank you so much.