 Alright. Hello everybody. My name is Pat Maddox and I am talking to you today about a tale of two code bases. And if you read the talk description or looking at the slide and are thinking, what the hell am I going to talk about? I am right with you. Because I submitted a couple talk proposals and I got an email back and they said, hey, you're going to speak. I was like, really, you guys chose that one? How am I going to do this? So, with that said, that's my official title in the Ruby community, which you guys may not know, BDDMF, that stands for Behavior-Driven Development MoFo. Dave Sholomsky gave it to me one time, which is kind of cool. But again, thank you guys for coming out. This has been a fantastic conference so far. So, Pat and Mike and everybody else involved, I really appreciate you guys throwing this. And the content has been amazing. I've heard that Mountain West RubyConf is the best and it hasn't disappointed. So, as we're kind of ending here the day and the whole conference, I hope to carry the baton, you know, until the next dude. So, really quick things about me. I work for a company called Goldstar.com. We sell tickets. This is me at Goldstar, really excited because we're having an ice cream party after a really good day. And I tend to get excited about a lot of things. One of those is Ruby. And this is a completely made up plot chart of my excitement with Ruby over the last five years. I'm not really big into long background discussions of myself, but I think this kind of sets the stage for everything. So, if you see here at the very beginning, oh, and this is, there's no scale. This is relative to Java, I suppose, is what this chart means. So, you see at the very beginning, and I hope Matt's is right there, he did not leave for this talk. So, when I first saw Ruby, I said, dude, it doesn't even have semicolons. I'm not interested. Because I had learned C and then C++ and then Java and it looked really weird and I was not interested. But my friend called me a dumbass and then told me about Rails. And so, I crossed the plane at some point over to, okay, this is a little cooler than Java. And then at some point, I wrote my very first Rails app, which was pretty fun. And I was like, hey, I'm getting a lot of stuff done here. I'm not writing EJBs anymore. So then, just a few months later, I actually made some money from Ruby. I had this website built in Rails. And as you can see, it goes way up. Because as soon as you go from, hey, I'm coding stuff for fun to, hey, I did something for fun and somebody gave me money for it. That's a pretty exciting event. So this was all a little over five years ago. Now, I guess, and after I had done that, a couple more months went by and I got to go out to San Francisco and work for my first startup. I was like, now I'm in the whole startup world. But pretty quickly after, I realized that $50,000 in Colorado goes a long way and rural Colorado goes a long way. San Francisco not so much. So it turns out that is the only kind of down point in my whole Ruby interest, which was when I'm like, oh my God, this is fun, but how am I going to buy food? So I got to go to my first Ruby conference. And this is where I kind of got involved in the community for the first time. I got to start meeting people. And as a silly story, I was a really big fan of Dave Estelle's work. You know, he wrote a test of a development book and an agile book. And I thought that was really cool. And my first day at the conference, I go in and I went to the bathroom and I was peeing right next to Dave Estelle's. And I was like, oh my God, that's so cool. And I actually got out and I texted my friend who told me about Ruby and Rails and I said, dude, I just peed next to Dave Estelle's. Well, this isn't on the slide, but about a year after that, I actually met Dave Estelle's and we became friends because somewhere in there I got really involved in RSpec and somewhere a little later, I got Dave added me to the RSpec core team, but I became friends with Dave Estelle's about a year after that. And then I think a year after that is when I finally felt comfortable enough admitting that story to him. So then I programming Ruby and I was with this company called Market 7 in San Francisco. And we worked with Pivotal Labs. I think there's some Pivot guys here and other phenomenal firm I had read about extreme programming for a long time and had done some of the practices. But when I went to Pivotal, that's where I saw how programming could be really, really, really fun. You get a ton of stuff done and it was just a really great experience. And then over the past year, I've been fortunate enough to go to Scotland and Hawaiian, Mount West, RubyConf and do all these really cool things. And I mean, I'm just like riding this highway right now. And so I'm telling you all of this because I hope it illustrates that I really love Ruby. And I don't mean I just like Ruby. Like it's fun to program and it's better than other languages I could be doing. But I love Ruby. I love coding this stuff. I love talking to people here. And a big reason for that is because if you go back on the slide about a year before that whole graph, I was playing poker online, because I dropped out of college because I hated software development in college. It turns out that what they teach you isn't really fun. And I thought, oh, God, everything that I've learned about programming is not the real world. And it turns out that playing online poker for living is hard. And so there was like a couple months where I slept in several layers because I couldn't pay the heating bill. So Ruby's pretty sweet. Now, but it really got me back into programming my whole life. All I wanted to do, well, I wanted to be a jet fighter pilot, but then I wanted to be a programmer. And Ruby got me back into it. And I was kind of very nervous about giving this sort of a talk, especially after Joe comes up here and fried my brain with that stuff. But it turns out there's some precedent in the Ruby community, right? There's DHH who we kind of know about. He says be happy. That's the whole point behind Rails. And Matt, he wrote Ruby so that you could be happy, right? Although I think in this picture, I mean, he looks really happy. But it turns out it's because he just like pulled the wool over the whole Ruby community's eyes with his Python buck. So, okay, so I love Ruby. And there's a couple things I want to say before we go on. So I love Ruby because it got me out of, it got me back into programming. But there's some real reasons to it, too, I suppose. The first is, I'm like an object bigot, I suppose. I like learning about functional programming and stuff. But when it comes to actually designing my code, it's all about objects for me. And so Ruby is a very low-ceremony object-oriented programming language. And then some other things like the metaprogramming facilities in Ruby are so cool. You can spend so much time sitting there just thinking, how can I mess with these classes? And how do I get objects to do things that they never really should do? And if you don't know, I mean, I assume everybody here is a pretty good metaprogrammer. So the way I see it, like learning to metaprogram Ruby is kind of like learning to date super models instead of former high school cheerleaders. You're just at a different level and you feel so much more powerful and it's pretty fine. I mean, not that I've ever dated a supermodel, but you get the analogy. And also open classes. Another program might have some really good ideas about how you should do things, but he doesn't know better than you do in your context. So having the power to open stuff up and say, okay, I like what you've done here, but I need to change it this way. And I don't need to write three different. I'm actually going to go kind of Yehuda style and say I don't need to have a decorator and a factory and a strategy to do some of this stuff. I can just kind of open it in, open up the class and redo whatever I want. That is another one of the reasons that has really hooked me into Ruby this whole time. So I love Ruby. That's cool. But I'm one dude. You guys love Ruby too. And a whole bunch of reasons I think that Ruby programmers love it, including the ones I just mentioned, but some other things like we're really, really frigging productive in Ruby. And it turns out that happy program or, you know, happy productive programmers are happy programmers. And that's kind of where I'm going at with this is that happiness matters. And that comes from the top down that comes from maths that comes from DHH. That is a part of our culture. And that's one of the things that separates us from some of the other programming languages is that your quality of life as a computer programmer really matters. So we care about a lot of things. We care about open source. They're not that, a lot of other communities are really big into open source. But we love being able to take some code out of our real apps and open them up and then come out and start to talk to people. So we love being happy. We know some of the things that make us happy. But it turns out that we tend to work for business people. I do. So how many people here have a boss and it's not you? So a lot of people, you're like coding Ruby to put food on the table. And what do bosses and business people like? They like money. Money makes business people happy. And I'm not going all communists here saying like they should not be happy with money. But what you have to understand is that dude looks really happy. I mean he is. He's got lots of money flying around. But he's also going to say I'll make you happy by giving you some money. But what you have to understand is like they're the hippopotamuses that eat the crocodiles. Like they will destroy you given the opportunity. And it's not even intentional. It's just like they're, you know, they're not aligned with you. They're not aligned with us in general. Like what makes them happy? They're willing to sacrifice things that we never should and that they never even think about and that we're the ones that have to step up. But there is a business case for happy developers. It's not this us versus them. We know that productive programmers are happy programmers, right? And productive programmers make businesses money. If you have happy developers there's lots of things that go into it. You've got clean code, right? Who here loves horrible nasty spaghetti code? We like our test suites and we don't just like having tests but we like having fast test suites and we like them to be explanatory of the code that we're working on. And we like them most of all to make us productive. And we even, this is actually really new to me as in after I saw Lauren's talk yesterday but we also like documentation with Yard. And so, so there's the programmer, you know, happy programmers are productive programmers and that's kind of a tautology because if you're productive then you're happy and if you're happy then you're more productive. But you also create this environment that attracts other really good programmers. If you have a team of talented programmers and they're really stoked to be there then you're going to start pulling in new good programmers to your team. You're going to be able to attract top talent. And that is, you know, something that every, that's something that your CTO cares about, that's something the project manager cares about but that's something that you should care about too is when you look to your left and right are those people as good or better than you or are you guys pushing each other and constantly taking things to a new level. So we want it, we want to be happy, the business wants us to be happy but we don't necessarily always agree on what to do there, how to get there. But one thing we can agree on is agility. Agility matters to us being able to respond to change, being able to add features really quickly, not having high bug rates but being able to get, being able to produce value on a consistent basis very quickly. So here's, here's this other chart that I made and this is slightly hand wavy too partly because I never actually worked in traditional software but from what I've talked to people and read. We have a, the development cycle is usually discussed in terms of months and years, right. People will work on the software for like this whole six month cycle and a year cycle and then maybe they release it at roughly the same interval. But if you look in agile literature and the traditional agile work, the developers work in cycles of days and weeks and they release in terms of weeks and months. Now this is of course, you know, not perfect across every single project but it's pretty representative of what the different groups do. Now Ruby is not really a methodology but if you talk to the Ruby programmers around here this is what you get. Programmers, Ruby programmers think in terms of hours and days. We finish, we create new units of business value in a few hours or in a few days. And we often release that on a weekly basis or two weeks, right. And is anybody here doing releasing their code three times a week, two or three times a week or every day? Anybody do continuous, continuous deployment? No, not there yet. Well, that's kind of cool. All that word, my code is definitely not there yet. But so this is called a tale of two code bases and basically I had this great idea for a story that I was going to tell that was going to explain how you approach solving all the inefficiencies in your code base over time. And I came up with this really great, I thought it was a great story. I told it to a bunch of people and they said it made no sense. And so I revised it and they said it made no sense and I tried, I did a couple iterations. And finally I threw in the towel so here's the picture of Jessica Alba commuting to work on a hippo. So back to agility. We can go really, really fast as Ruby programmers and that makes our business people happy. But sometimes it's important just to slow down. And Agile, the Agile community actually has a term for this. They call it sustainable pace. I'm sure you guys have all heard about sustainable pace. What this really means to me is that not all 40-hour work weeks are created equal. If you guys aren't familiar, I mean there's a, there is a programmer having a very good time on the beach writing, writing her Ruby code. And then here is a scene from Deadliest Catch where they, I don't know, they catch crabs up in the Arctic and it's really crazy and people die. So, and I don't know if they actually put in the same amount of work per week but you can imagine that in any given 40-hour work week or however many hours you work in the week, depending on different factors in your environment, you will either come out of the end of that week very energized and, well, I mean you're going to want your weekend still, but you're going to come out energized and excited for the next round of work, or you're going to gradually, like, your energy is going to be chipped away over time. And that's kind of, that's what we want to avoid. That doesn't produce happiness for the programmers over the long term and you burn out and companies lose their talent, they jump ship. So here's a little shanty town and I take this because Dan North, he's one of the original, well I guess he is the original behavior-driven development guy, and he talks about how software is built as a shanty town. That unless you do a ton of architecture up front, what you have is this little village of the system of small houses and markets and other buildings that all function reasonably well, but it doesn't scale, right, and it doesn't scale in, like, handling however many requests, but it doesn't scale over the long term, like, that is, if you want to have a million people live in that city, that's not really the way you want to go about it, right, and that's the difference between working on a software project over two months versus over two years, and this starts out perfectly fine, that this is, this is what you need to do, you need to get users into your community and you need to provide something that works, but over time if you live in a, in a town with, without roads, then, then commerce slows down, and if, well, I mean, if however much commerce they really have, and if you have, if you don't have sanitation, then people get sick and die, so that's no good. So you have to think about the different ways that, that we ever want to, to, to improve our projects so that we can continue to add value, continue to be happy productive programmers, and there are tons of different ways. You guys can all look at your code base, I mean, all you have to do is, you've all seen the comic about WTFs per minute, that that's the primary indicator of code quality, I don't have that here, but if you, you know, you look over code and however many times you say WTF, WTF, that is, like, high WTFs, bad code, low WTFs, good code. Well, you guys all know the bad parts of your code, all the things that you would like to change, if you're working on rails, and your test suite is slow, and if you're working on rails, then your test suite is slow, then you want to speed it up, and there are various things that you can do, you can start to decouple parts of the code, you can, you can move stuff in memory as much as possible, like if it doesn't need to hit the database, then don't hit the database. Other things, like you want to upgrade to the latest version of rails, or there's some new plugins, or you want to move, you want to start moving your stuff to no sequel, because as we now know, MongoDB rules, and these are all things that you can take, and I was going to give you the specific strategies for doing this stuff, and like how to test and how to refactor, but when I was doing the whole know your audience test, I realized like this is the group that already knows this stuff, you guys are not the ones that I need to teach how to refactor, you guys are the ones that I need to somehow get you so impassioned to go back to your teams, and drive this into their heads, like drive it into their freaking skulls, that this is the stuff that they need to be doing, because otherwise it's going to make your life miserable over the long term, and so the first thing that that we do is we demand excellence, and this is this is of ourselves, this is of our team members, this is of our bosses, this is saying that we know what needs to be done as as software engineers, and yes we make concessions sometimes to get stuff out to hit a deadline, but the majority of the time there is always time to refactor, there's always time to get the test in place, that's a fight that you can have with your project manager, but over time if you don't follow this rule, you will burn out, you will quit, you will drive the other developers away from your team, and this is, this requires immense focus, you have to be, because people are always trying to pull this, pull this spirit away from us, they're always putting their needs before everything that we're trying to do, that's just a natural human thing, but we have to push back, and if you're not focused then it's epic fail, and I would like to say that this came from some random failblog internet picture, but this is actually my car over a ledge when I was, and the worst thing about it is that it was in front of a subway sandwich shop at 8 p.m. on a Friday night, which means that the tow trucks weren't working, and so for the next two hours I got to tell the story to people of how that happened, okay well that's not my fault, that ledge you can't see it when you're, when you're parked there, and according to the lady that works at subway that happened to three other people in the previous year, but I also never claimed to be a good driver ever in my life, so okay so we demand excellence, but the next thing is you can think of 10, 15, maybe 20 different things that you want to change in your code base that all require an immense amount of work, so the next thing that you have to remember is not to bite off more than you can chew, this I guess you guys just got in and out, good for you, this is a 100 by 100 patty, you know hamburger at in and out, and I have no idea where you would start with that or most of all why, but it is, but I think that that provides a good, like if you're thinking hey I want to have, you know, if I'm going to start eating hamburgers I'm going to eat a lot of them, like that will kill you, and trying to do the same thing in terms of your code base, if you're focusing, if you're not focusing, if you're spreading yourself then, and you're trying to change fixtures all the time, and you're trying to add new test coverage over here, and you're trying to migrate some stuff to manga, like that is, it creates such an emotional drain, because you're making very little visible progress, overall you might be inching towards your goals in four different areas, but it doesn't feel like you're getting where, there's no sense of accomplishment, and that's another one of those things that just really drains on a team, and like in terms of, and this is really important, I forgot to mention this, but buggy code, like we all hate buggy code, but there's nothing that causes programmers to fight more than buggy, difficult to understand code, like I don't know how many people have gotten in shouting matches or IRC shouting matches over buggy code, but I've definitely seen it happen, we got a couple takers on that one, I've definitely seen it happen, and so this is the, I think that there's a really strong business case for why, why we need to focus on this, and be absolutely committed to the solid engineering practices that that we know, in terms of how you actually go about and do this, well I said, don't bite off more than you can chew, but one strategy you can take is to do themed releases, and this is something that I had heard about, is anybody familiar with having themes for their releases? No? Okay, so a couple, my friend BJ Clark, who also did the, who's also the nature photographer slash paparazza, who snagged that incredible photo, he told me about themed releases, and the idea here is, it starts at a business sense, that if you're working on, if you're doing agile development, using something like Pivotal Tracker, you might have 200 stories in the backlog, but when you actually plan out an iteration, you want to create a theme for that, so we're going to work on search, or we're going to work on user management, and the vast majority of those stories that you work on will be in that specific area, and then with maybe a couple other high priority things, or easy fixed bugs, slipped in there. The idea being that you have a cohesive set of features that provides a bunch of value to your users that's visible, but at the same time, when you're working in a single part of code, like if you're working in a general part of functionality of your application, then that is where you really get the opportunities to make all the positive changes that you want to, because if you've got four programmers, or however many your team is, working in a single general area, and you all notice these efficiencies, it's hurting everybody at the same time, so in terms of making these sorts of changes, having business-focused themed releases is really important, really helpful, and you can also do that at a technical level. If you schedule a separate time for chores, developer chores, do the same thing, say we're going to focus for the next week or two or three weeks on only making these certain sets of changes, we're only going to remove fixtures, or we're only going to migrate tables over to MongoDB, we're not going to spend that much time on the other stuff, because we know that if we focus a bunch of energy at once, especially if we have the whole team focused on something at once, you guys got sneak peek, then we're able to make, then we're able to get to where we want to go much faster and ultimately have a better programming culture. So one other thing I want to talk about is I've heard about technical debt in the last six months or so, last three months, and it's really nice to hear, although I think the way that people talk about it is a myth. You guys are all familiar with technical debt here. Is anybody not familiar with it? Okay, so technical debt is the idea that you're making, you make trade-offs over time, where as you as you work on code you make certain design decisions that you know are not necessarily the optimal design decisions at this point, and it's going to cause you some pain, but it delivers enough value now that we will just fix it later on, and the metaphor is a debt metaphor because it costs interest. If I make suboptimal decisions now, I have to pay some interest on that in terms of the potential for there being bugs, the other developers not being able to understand a certain amount, a certain part of code as much, and just the mental context that you have to recreate anytime you go back into that. When you're working on, the best time to solve a problem is right now when you know what it is, because you've developed mental context for it, and if you go back to it six months later, whatever little things you've figured out, you're going to have to figure out over again. So that's technical debt, and I think it's a myth, although that's probably a bit strong. I think when people talk about technical debt for the most part, it's really an excuse. It's an excuse to not work on as great as technical debt is, the term, as far as providing programmers a metaphor, it's been horrible because you can sit down with your pair, and you can look at that part of coding and say, that is really bad, and since we're right here, I think we should change it, and then your pair goes, well that's technical debt, we don't have to do it right now. So this has been, put it on the credit card, and maybe that's the, I mean maybe because we live in the United States, and like there's a lot of debt and people, you know, it's a pretty common thing that, okay, so economic crisis will happen to your code, and so it's often used as an excuse, and so that's just something to keep in mind. Keep the technical debt metaphor in mind, but recognize that it, I mean that has to be a very, very explicit decision, and it's not something that you should really take lightly, and anytime you have the chance to chip down at your technical debt, do so. So final thing I've got here is, I don't know if you guys can tell, I'm really passionate about Ruby and I'm passionate about software, and this stuff is very important to me, and I know it is all for you guys too. You know, you're 300 programmers out of the entire Ruby and Rails community, you've been to conferences before, and people say that you are not the average programmer, you're the, you know, you're in the top 1% or whatever it may be of being interested in this, of solving problems, of creating new knowledge, of sharing this stuff, and so it's very easy, it's easy for me sometimes to get lost in the, you know, the trivialities of my daily work, and to lose some of this, to lose sight of this, and to not hold true to my principles some of the time, and that's something that I never wanted to, you looked at that curve like, I'm really, really fucking happy to be a Ruby programmer right now, this is a good place to be, this is a good place for everybody to be right now, and this is something that we are able to share with the rest of the people in the community, the people on the mailing list, the people that aren't here, the people who should be here next year, and that's most of all what I hope you guys take away from this, we have a brilliant community, we've got a beautiful language that allows us to be really happy, that allows us to make connections with people that might be difficult to do in other communities, and that's something that we can never lose sight of, and you know, just keep it going, so that's it, for me there's my very creative email on Twitter and GitHub, and I realized I kind of felt like an ass for not having any Ruby in a Ruby talk, so I've got a couple minutes for questions, and it's actually one minute and 30 seconds roughly, they're cool with it, so here's the other thing, you guys are all familiar with somebody making a very sarcastic, do you want a cookie, say like if you do something, we'll say do you want a cookie, and I think it's very disappointing when I say yes, and then they look at me like a dumbass, so to avoid the whole embarrassing scenario when I talk for 25 minutes and then get nobody to answer, ask questions, if anybody asks a question, I have cookies, how about that, okay right here, yeah come get one okay, but that's the last time somebody pulls that trick, any other questions, yeah up here, so I absolutely love pair programming, and that comes from very very good experiences at Pivotal, I got to work with some really cool people, you guys know Nick Callan, he wrote HasFinder that became namescope and then and then he like basically wrote Arrow, which is now, so like he's brilliant friggin dude, and the biggest benefit to pair programming is your, well two things, from a productivity standpoint, you are working eight hours for the day, like nobody's checking their email, you hear that all the time, but it's just like two brains think better than one, and oftentimes when you get in sync with with a pair, then you guys kind of finish each other's thoughts, or you, very small course corrections, right, if I'm going down a certain path and I'm making this, I'm about to make a small error, my pair might notice it because he's not, he's not digging into the details quite like I am, so he's able to look at it on a broader level, but I know that some people really don't like it, and various reasons for that social thing, like it's really fun to code alone, you know, I mean everybody here codes alone every once in a while I assume, and but other, if you have a negative pair experience, if you're working with somebody who hasn't paired with a lot of people, or he or she is a very, very dominating and doesn't accept your ideas, that is incredibly frustrating, nobody likes to go to work every day and be told that they're wrong all the time, and that's, I have seen that happen with pairs, so if you're pairing with somebody, don't do that because they're going to think you're an asshole and it's not going to be fun, and then the next time I tell somebody, hey, pairing is really cool, you should do it, they're going to be like, no, no, no, pairing sucks, and here's why, well that's because your pair sucked, so, want a cookie? Yeah! Alright, any other questions? Chains? Ooh, okay, that's really good, so the things that have been, okay, the books that have been most influential for me, supposed to be, I read Small Talk, Best Practice Patterns by Kent Beck, and then he kind of updated it for Java with his implementation patterns, that was a really good one, the two other books that everybody needs to read is Design Patterns and Refactoring, who here has not read Design Patterns, okay, so a few, and Refactoring, same similar thing, so go out and read those, those are, that is like the basic mechanics of our craft, like Refactoring is the basic mechanics of how do we take our, like, it gives you detailed step by step by step, of this is what's wrong with your code, this is how you fix it, and this is why that's going to be a lot better, similar thing happens with Design Patterns, I know that we look at Design Patterns and say, oh well that comes from Java, although, is you heard it still here? Dude, there's no Java in the Design Patterns book, so stop that lie, C++ and Small Talk, those are the languages that are in the Design Patterns book, so the link between Design Patterns, Java, complete myth, those are the two, and you should be looking in your code base and you should be able to identify patterns, even if you don't explicitly put those in, they should, you should see them, you should, oh that's it, you know there's a strategy pattern there if you're making certain decisions, because it's not that those are a la carte design choices that you make, but rather they represent these proven solutions to various forces that everybody experiences, so whether you know it or not, whether you know that you implement a certain design pattern, doesn't really matter, but the point is you're going to, your code is going to be experiencing certain forces on it, and there are good ways to resolve those forces, and there are bad ways to resolve those forces, and Design Patterns helps you know what are the good ways, and what are the bad ways, and what are the various trade-offs, and not that you ever actually stick to everything listed in that book, but you should know it because it gives you all the trade-offs and all the forces, and that's pretty important, so I think that's it, well thank you guys very much, it was a lot of fun, and enjoy this next talk.