 All right. So I thought I would, well, I guess you guys all know, Mike is kind of a polarizing figure. And I wanted to sort of frame my discussion about the 10 years I've had, awesome years I've had working with Mike in this sort of trying to give you a little bit of a sense of what it's like, and sort of maybe help you to interpret the way that he views the world. So I think I was supposed to talk about his impact on New England research. So I thought I'd just say a couple words. It's really hard, I think, to underestimate how much and how influential Mike has been on the sort of New England database research community. I mean, you probably heard from Stan a little bit about the work with Streambase, but the work with Vertica and C Store, the work on H Store, all these systems that have brought a group of us together and are really, it's been a really incredible experience to have these very, very close collaborations here with many of the people in this room. And it just wouldn't have happened if Mike wasn't there to make it happen. So it's just great that he's done this. And I'll try and convey that a few of the things that he has done and some of the contributions he's made in this talk. So as you know, I guess you guys all know Mike says kind of bold things. He tends to take a very black and white view of the world. Either you're in or you're out. Either what you're doing is great, or it's a fate worse than death. He says these things that are just very controversial. So I'm going to illustrate what I've learned from Mike. In three sort of short little vignettes. So the first one is sort of what I've learned about how to be a researcher from Mike. So I'm going to start by just talking about these couple of systems that we built together on the C Store system. So analytical databases. For those of you who don't know what an analytical database is, it runs queries like this. This is a SQL query. So it computes some simple aggregate over a whole bunch of data. So the way that Mike's approaches research problems is sort of like this. This is before C Store and Vertica showed up. This is what everybody else was doing. It was this very kind of gray, complicated picture of the world. Database systems were, oh man, they had all these features like, they were designed to support these analytical queries like indexes and hybrid storage models and materialized views and data cubes and decomposed storage and all this stuff that everybody had been doing for 20 years to try and support this. And Mike said, what is wrong with you guys? This is just wrong and complicated and this is what it should look like. He had this very simple picture which said, we're gonna build columns and no, we're not gonna do it and you said, but Mike, shouldn't we do hybrid data storage? We could group columns to get no, we're not gonna do any of that. We're just gonna build a system and it's just gonna be based on columns. And he had this very clear, crisp ideological view of the world and he pushed it. And the way that Mike does, just relentlessly marketed this idea and just painted this very simple, clear picture of the world. And lo and behold, here we are 10 years after this project. You look at every single major database system that tries to support these kinds of analytic workloads and what are they doing? They're building a column store or they have built a column store. And it's just, it's an incredible, and it's not that Mike was the first person to say you could vertically partition databases. It was that Mike was the one that said, if you do this, it's gonna be 100 times faster than the way that your current systems work if you build it in the right way and here's the right way to build it. And it's just, it's hard. I don't know how Mike does it. I don't know how you like have this clarity of vision. So it's incredible. All right, so that was Vertica and Seastore. I just, I wanted to give, I went back, I was trying to find an example of a quad chart from these days and I found this one email from DeWitt that said something about a quad chart but it was so nonsensical that I couldn't put it up. But I do, I mentioned ASCII, ASCII. So Mike likes to draw diagrams that look like this. That's an actual diagram from the first Vertica paper, first Seastore paper. And I was a assistant professor at the time we wrote this paper and I just said, I can't actually send a paper with this ASCII diagram. So I re-drew the diagram to look like that in the original submission. And if you stare at this for a minute, you see Mike's diagram doesn't have an arrow at all. And I had this great innovation was put the arrowhead in there. But the arrowhead's actually going the wrong way because, anyway, whatever, it was a low point, okay? All right, so the next project I wanted to talk about was this in-memory database work. So this is the work that Mike has done on we call the HStore, but the Volt has been commercialized as Volt. And again, it's another one of these examples where Mike just has this clarity of vision that is really pretty incredible. So these are systems like this, they process, these are transaction processing systems. So unlike trying to compute the total number of shirts sold, we're just buying one shirt now. And the way that these systems have worked in the past is, well, this is what systems like Oracle do. They're these big complicated systems that are millions of lines of source code. And if you look at what they actually run, well, you look at sort of where they're doing, they spend a little bit of time answering queries. And they need to do all this other stuff that the people who build these systems say, say, you, is that right? Yeah, sorry, I got the screens wrong. The people who build these systems say, boy, we need all this other complicated stuff in our database system to support, oh, I don't know what backups and logging to disk and just endless little features that these systems have. And Mike looked at this picture and he said, you know, I could build a system that's 100 times faster than this, and here's what I'm going to do. He said, well, this is the time that, you know, you actually spend doing useful stuff. And the rest of the time is just crap that we don't need. So let's get rid of it. And he's run around sort of this vision. Again, then he said, and by the way, here's how to build a system that doesn't have all this crap in it. So he sort of took this little insight and then said, we're going to make all this stuff that we don't really need going. And again, it's just this sort of incredible vision ability to see the way in which other people are doing things wrong and to just relentlessly push towards that goal. So the lessons that I take from this, first of all, it's like it's really easy in research to come up with a million ideas, which are all pretty good. It's really hard to come up with one idea that's really good. And that's what it's a lot easier to sort of, if you can come up with one idea that's good and is the good idea, that's the one you should stick to and you should push with it. Don't write 20 papers and have 20 little ideas. It's much better to have one big idea. And then a related idea is this get some ideology and stick to it. Mike is fantastic at continuously and relentlessly pushing his viewpoint. And you see this over and over again, and it's part of the recipe for his success. It's like, we take this idea, like Seastore. It's a great idea, and he's right about it, and he has a great conviction to make sure the world believes it. So I'll come back to this a little bit later. All right, so the second thing I want to talk about is Mike as a collaborator. And the way I wanted to do this is sort of, Joe stole a little bit of my thunder, but I think you'll still appreciate this. I wanted to, for those of you who maybe haven't collaborated with Mike or are just starting a collaboration with Mike, try and help you to interpret what Mike really means when he says different things, OK? So here's some things that Mike has said to me or to people I know. Like, that's the stupidest idea I've ever heard, OK? So when Mike tells you that's the stupidest idea you've ever heard, what he means is I see your point, but I'm not sure I agree. You need to do a better job of making your argument, OK? So, again, it's just a very black and white way of saying things. But because Mike says your idea is the stupidest idea in the world, don't be discouraged. Just try and convince him of your idea. And as we heard earlier, you, in fact, can win an argument that begins with Mike telling you that your idea is the stupidest idea in the world, OK? Let's have a group grow, all right? Part of what's funny about these things on the board is actually many of them Mike doesn't say anymore. He's getting developed some new funny expressions over time. So group growth seems to be on its way out, but it was popular for a few years there in the middle. And it seems to mean something like let's get together and figure this out, despite what it might sound like. There's a related one, which is let's have a come to Jesus meeting, which I think also means essentially the same thing. Let's get together and figure it out, OK? All right, so I like this one. MapReduce is a poor implementation. And I like this one because it's, well, Mike doesn't write code, so it's not. MapReduce itself isn't really an implementation anyway. And even if we're in implementation, it's probably not a poor implementation because it was written by this guy, Jeff Dean. And I don't know if any of you know who Jeff Dean is, but he's considered to be the best programmer in the entire world. In fact, there are these websites about Jeff Dean that say things like, compilers don't warn Jeff Dean. Jeff Dean warns compilers. It's like the Chuck Norris thing, where people say these things about Jeff Dean. So Jeff Dean writes directly in binary. He then writes the source code as documentation. That's Jeff Dean. So what Mike really means is MapReduce is not. He doesn't think MapReduce is the right abstraction. And then the last one, well, a couple more. Running Facebook is a fate worse than death. Well, what does he mean? He means I wouldn't have done it that way, but it seems to work OK for them. And finally, when Mike says no, no, no, no, no, which I have several emails that say this, I'm trying to convince people that they're doing it wrong. He means no. All right, so what are the lessons? One lesson I take away from this is that it's actually really, really valuable to tell people what you think. I think in academia, my tendency is to say things like, oh, well, that's a really interesting idea. And actually, it's much better to just tell people that if you think an idea is a bad idea, or if you think that they're doing it wrong, tell them and then have a conversation about it. And it tends to end up at a result that I think is actually much better than being equivocal. Be controversial. I think people pay attention when you say, you see, Mike is able to, obviously, Mike has a lot of gravity. People listen to him when he says these things. But being controversial will get you to people to pay attention to you in a way that, being passionate about what you say, I think there's a lot of value in that. And finally, it helps to be right. And more often than not, Mike is right. And I'm not exactly sure how he is right as often as he is, but it's pretty remarkable. The last thing I wanted to say was just a few words about Mike as an entrepreneur. And I'm hoping that Andy will say more as Mike as an entrepreneur. I think I feel like looking at the sort of startup community in the Boston, New England area anyway. And Mike is about your fifth company, sixth company. I don't know how many companies. But I think he's single-handedly reinvigorated at least a certain part of the database, sort of, or enterprise entrepreneurial community in the Boston area. And it's been a tremendous contribution. I think a lot of people really appreciate Mike for that. I wanted to sort of talk about Mike's style for founding companies. I think Mike has really, he's figured something out. And it kind of reminded me of the underpants gnomes. So you guys maybe know this thing. So the underpants gnomes were the, this was a South Park episode. And the underpants gnomes had this great business plan which began with collecting underpants and ended with profit. And the only thing they had to figure out is what came between underpants and profits. And it seems that Mike has figured out what comes between underpants and profit. Okay? So, all right. Anyway, it goes something like this. We already talked about this a little bit. You identify a greater than zero billion dollar industry. You identify something your competitors are doing wrong where, generally speaking, your competitors are horrible. Okay? And then you ruthlessly exploit it. So, and then you get profit, okay? All right, so that's what I wanted to say. I have something, I have to grab a prop, hold on. All right, so just to conclude, I want to say thank you, Mike. It's been just a tremendous pleasure working with you. I couldn't have imagined a better collaborator over the years. And I'm really looking forward to many, many more years doing this. This is a picture that we took, what was this in October? So, this is five generations of database researchers. So, that's Mike, that's Mike, that's Mike. So, this is Mike Kerry and Mike Franklin. So, Mike Kerry was Mike Stonebreaker's graduate student. Mike Franklin was Mike Kerry's graduate student. I was Mike Franklin's graduate student. Unfortunately, I broke the mold. I'm not named Mike. Dan Avadi was my graduate student, also was not named Mike. But we're all together at this event. So, it seemed like a great opportunity to have five generations of database researchers descended from Mike get together. There's also something else I wanted to point out, which is that there seems to be a trend. I'm a little bit of an outlier here, but if you project this trend forward, we're going to have some very short database research. So, thank you very much, Mike. We have a signed version of the picture. That's all I had to say. So, happy birthday, Mike. Thanks very much.