 This is about future proofing your software, Braille's applications are now nearing a decade old, nearing puberty. This talk is about the things that you can do to compare your applications for adulthood. I'm going to ask some questions, maybe a couple, I'm just going to talk after this. So this is me, I write some things periodically at SteveAndRBG.com, you can reach me on Twitter. My Twitter feed is really bolder, so people weren't in advance. Email me and tell me how much this presentation sucks, that's awesome. Mostly I would like to just talk about these ideas, these are ideas that are developing. These are ideas, we can start a little club, like at my daughter's school we have a parents advisory council and we sort of get together in a little club and talk about how we can raise our children better and make their education better so we can have a little club and talk about how to raise our applications into responsible mature adults. So my first computer program was when I was eight years old. I wrote a hockey trivia game, let's go and cover that in Canada. So the hockey trivia market is underserved, there are very few of those applications now. But what I learned in my first version of my hockey trivia application was that everything was like, I learned in basic how to print out some text and ask somebody to type in an answer and then tell them they were right or wrong. And that was fun. And when I wanted to add a new question to my hockey trivia game, I copied the last one and pasted it in the text because I'm sure a lot of you guys do that too. We all do it from time to time. So over time, my hockey trivia game became one of the most important. I refactored it, but eventually it just got to the point where I couldn't do anything more with it. I couldn't add new questions. I couldn't add new questions, I couldn't make it more interesting and it sucked that I was devastated. I was a very unhappy little career grader. So the hockey trivia market is underserved as I said. I mean, how many hockey trivia apps are out there? And so if I knew how to write mechanical software when I was eight years old, that market would be covered. But I didn't. And so since then I tortured myself and worked on how do I make my applications future-proof. What decisions that I'm making today affect the things that I have to do to fix my application tomorrow in five months from now and five years from now? And those are really interesting questions. And sometimes they're not obvious. Sometimes the decision that you made that sounded perfectly reasonable six months ago is really holding up things now. And let's see. So because of the time that I learned Rails, which is the week after it was released, my focus on quality and testability and future-proofing your applications, most of the six years that I've been working in Ruby and Rails nearly exclusively haven't spent doing firefighting games. So people very often call me when they have the worst code ever and can you fix it? And I can't always fix it, but I always learn something. And that's what this is. It's a dirty job, but somebody's got to do it, right? So Pac-Man is an example of something that exists forever. We played Pac-Man last night over here in the Sport Player Pac-Man. It's awesome. I went to the bar and asked where are the rest of the nerds from the conference? And Matt said, I have no idea where all the nerds are. I've been playing Pac-Man. So we never did find the nerds. We just drank beer and played Pac-Man. People still play Pac-Man today. We played it last night for a while. It's an application. I mean, it's a very contrived example. But it's an application that was written a long time ago. It was first released in 1980. And people still do it. People still play Pac-Man. I'm sure it can be rewritten and stuff like that. It's a very contrived example, but software often lasts a lot longer than you think it will. And Pac-Man is probably a great example of that. I mean, how many people still play Tetris or are very Tetris? Right, I still play Tetris. And I'm sure that when Tetris was made it wasn't going to be, you know, people are going to play this for 30 years. I don't think that's what they had in mind. But people do. And so people are going to use your software for way, way longer than you want them to. Right now I work in the finance industry. We transfer money between banks. Steve forgot a slide where he talked about RPC and stuff like that. The other form of API is when you're talking to software written in COBOL in 1975, is you take a CSV file and you FTP it somewhere. And so this is, I mean, oh, it still works. This is software that was written a long time ago. And we interact with it every day. So it's really important to think about these things. So for me on Rails apps, as I said, they're getting to be like a decade old. There are Rails ads at the wild that are going to hit the decade in production milestone very soon in just a couple of years. In five years, we will have many applications that are written on Rails that have been out for 10 years. And it's amazing. So how many people here are working on Rails that's more than a year old? Three years? More than three years old? More than five years old? Okay, so a couple. All right. So for the people who are working on apps that are more than five years old, keep your hands up. Keep your hands down if there is poorly thought out code legacy decisions or stuff you wish you didn't have to deal with. There's a lot of it out there. So Rails makes things, makes easy things really easy. You can get a blog in 10 minutes if you want to build an application that's a little bit longer than that. But most of us get started with the 10 minute blog. I get started with the 10 minute blog. I've never deployed a 10 minute blog. So at some point you have to improve. You have to think a little bit longer term about your problems. To build large application software, you need to plan for the future a little bit. And I'm not talking about big upfront design because I hate that as much as the next guy. I'm talking about just simply be aware that what you do today needs to be maintained and supported tomorrow and may not be maintained and supported by you as a small community. So be nice to your peers and leave them these things as well as you can. So I want to thank Joe and Mike Moore, but you don't know that yet because I think it's late today. At lunch today, a friend and I were talking about the theme of some of the talks today. We're very pleased and excited by the fact that people are talking about basically maturity in the Rails community. Things like object-oriented design are coming out. Things like my talk and Mike Moore's going to talk about things like that as well. And Joe talked about, you know, here's how we move forward. We're talking about, we're talking about how to prepare ourselves for the future. I don't see old as being necessarily a bad thing, especially in software or in cars or people. In most things. My daughter probably thinks I'm too old to be cool. I don't think I'm getting older. I'm just getting better. And I hope that everybody here is getting better. I'm going to talk about some things for making your app get better. And so everyone knows when the pocket was slide, that DHH made it head on Rails in 06 and what he had to say about the enterprise and what he had to say about the status quo. Well, in 2012, we are the enterprise and we are the status quo. And I don't want the next framework people to be going and saying those things about us because we left them messes and we left them in a bad spot. And so we're learning things now about what we can do for the future. I once built a house with my dad a couple of years ago in Canada in the winter. And if the roof was on, we started every day by shoveling a few feet of snow off the floor. That was the first half of the day. And I learned more about software development in the six months or so that I spent part-time helping my dad build his house that I did in the decade prior to helping my dad build his house that I spent writing software before that. And this is why I'm a fan of the craftsmanship movement. There are a lot of parallels between building houses and other trades and writing software. We can learn a lot from the construction industry. A large part of the construction industry is for renovating and modifying existing houses. It's a very low barrier for entry industry. Anybody who swings a hammer can probably get a contract in a renovated bathroom. Won't necessarily do it well can get the contract. We have a TV show in Canada Yes, isn't it awesome? Okay, so Mike Holmes is an awesome upper Canadian dude that goes in and cleans up messes for a large part of the time that I've been working on Rails apps I've been to Mike Holmes on Rails apps and it's just where we are. So, in the software world instead of, you know, adding or improving a house or, oh my god, I just said house I've been waiting. So, instead of renovating houses we will do the software when we renovate a house we add rooms to it we improve existing rooms and things like that. Building new houses is an important part of the construction industry but when someone wants something of other house changed, they renovate. In the software world, very often when somebody wants to have something changed that could proceed via big change like making your garage taller than you can see in a moment. We do what would be the construction equipment with bulldoze in your house and building a new one. It's been a number of years since I helped my dad build this house I don't remember exactly how many my block was to be out it was like 40 below, most of the time. Soon it'll be time to replace the roof you have about 10 years of a roof If the constructed industry imitated the software industry my dad would be calling me and saying why don't we try the bulldozer because we get a leak in the roof I don't want to see that I don't like seeing that in software but being better about what we're doing we can stop bulldozing our software and so it's not about the cost it's not possible I thought for a while maybe we just bulldoze and redo software because it's cheaper than building houses but it's not actually many renovations to houses raising in a level many of those renovations cost very close to the price that it would cost to bulldoze the house and build a new one I did it again my accent is immediately unapparent the equivalent and the equivalent in software costs far more you can bulldoze a house and build a new one in the time and effort that it will take to bulldoze and build a new house that time and effort will cost a lot more in software typically especially when there's a high demand for people right now which is why you should be getting ahold of Mike R. M. Josh very quickly so this is Steve Simmons' house he's a member of an online community for MG Nuts he comes from MGNuts.com a British car fetish this guy had a garage he needed a bigger garage because he liked British cars he wanted to bulldoze his house to get a bigger garage he used to be the current garage bigger and I suspect he's going to have to build a bigger garage at some point as well this one is looking a little bit tight that was the day after it was finished so I think he's going to need a new one soon in the software world we want to bulldoze his house to get a bigger garage we can do it again later I don't like seeing that so as your app grows there's some pain associated with that sometimes things take longer than you than you'd want them to and a lot of teams are noticing that development speed slows over time this is usually a result of poor decision making and think about it if you learn about more about your domain as you go and you get the foundation laid for building new features and things shouldn't things go faster over time shouldn't those little features just be faster to implement and they should be in real and extreme programming the XP cost of change curve is going to be flat or over time it will decrease as you understand more about what you're doing but most software projects aren't experiencing this because they're doing they're not planning for the future appropriately and they're being hasty and responding to things quickly what they need now rather than what they will need for the future so I'm going to go over some of the things that will cause a future pain or some of the solutions one of the ideas is really important is convention over configuration another 20 years from now when Rails is a distant memory when when Rails is what cobalt is now when everybody laughs that I have to interact with the cobalt system right in the 70s 20 years from now people are going to laugh when you have to interact with that oh my god you're writing software so I'm just going to say how do you deal with yourself and if nothing else if we learn nothing else from Rails from our time spent developing Rails apps and changing the way we think about problems convention over configuration is the one thing we need to take with us this is the best idea in Rails I think there are many great ideas in Rails there are a lot of things that are pulled from other places there are a lot of things we do wrong this is the good one I don't remember this still do some configuration when you need it convention over configuration doesn't mean don't use configuration it means that if there's a sensible default assume a sensible default your Google Maps API key is not a sensible default that's configuration value the place and the manner in which you report your exceptions that's also configuration that's not a sensible default but those are application specific very often if you have conventions it helps your team get up to speed on your app and know where things go and do things need to be added what does it look like who do I talk to those conventions not just in software not just the low level day to day writing code conventions the conventions for how do you attract your team members and things like that how do you solve problems those are great conventions to focus on there's often a discrepancy between a Rails convention and an object oriented convention or a Rails convention and the way that a lot of software shops operate things like that this is where you're going to have to make a lot of really difficult decisions for some reason the Rails community calls templates views and they think the Rails MVC even though there's no views in Rails there are just templates and decorators are called presenters and REST is not REST and these are not things we're going to get away see, pointed out we can't reteach people that what you call REST is not so we just have to stop using those words I don't think we have to do the same thing with templates and views and decorators and presenters because they'll use everywhere else people know what decorators and presenters are in other communities small talk it's always great to compare things to the small talk community because Ruby is just called Ruby because it hasn't been perfected yet small talk was called small talk 8 because that's when they perfected it perfected in 1980 so when we perfect Ruby it'll be called Ruby 36 so team conventions if your model doesn't inherit from active record base, what is it? it's still a model some teams call those libraries some teams call those services but it's still a model whether it inherits from active record base so these are things that affect how you think about designing your software because if you think that a model has to have an associated database table that affects the design of your software and they're important decisions that are made because of this this is where your team has to make a judgment call you have to decide what is called a model and things like that and this will vary from team to team but you need to avoid violating a convention every time you violate the conventions you have to cover it in two places number one you have to cover in the code sorry the configuration where you violated this convention you have to configure for that I mean one of the most common examples and I don't recommend against using RSpec obviously but when you use RSpec you have to change some of the configuration to do that and you have to ask yourself since the test unit is the default and I want to use RSpec the value that I'm getting from using something different worth the cost of changing that default and in Rails 3 that cost is almost nil but back in Rails 1.2 or earlier it was really difficult to get to that place where you could reasonably use RSpec and they stopped assuming that you were definitely using test unit so you have to document it you have to cover it in the configuration you also have to cover it in the documentation when I'm ramping up on your project or when I'm looking for where things go if you're bringing someone new on your team you need to be able to go to one place and say hey why is this not acting in the same way that it did in the last project that I worked on your application is famous for saying you are not a unique snowflake your application is not a unique snowflake I bet there are very few people in this room that are working on something that has truly never ever been done before and so we want to be able to have new people joining your project know what's what whatever little bit of extra domain specific knowledge but if you're working in a complicated industry we're working in the finance industry right now for instance there's a lot of domain knowledge I need to learn I don't want to have to learn all the ways that my team has broken the Rails framework as well as all of the domain knowledge but I have to learn as well so just to ease on working and when Rails upgrades come out anybody who's done a Rails 3 upgrade recently I see some really sad people you guys have done Rails 3 upgrades recently so that's these are the kinds of things when you break the convention you pay for it when you do a Rails 3 upgrade those are important things as well generating code is a huge issue for a lot of projects that I've been on as well every line of code has a cost associated with it and that cost is the price that it cost to maintain that line of code so if you have a class that is a hundred lines that class probably costs twice as much to maintain as the fifty line class again temper this with a metric asked on a solve but in general these things are really important if you are Ruby is really dynamic if you're generating code you can definitely be calling it from somewhere else so there's almost no good reason to ever be generating code in Ruby generating code is actually more expensive to maintain the code that you wrote using any of the conventions domain knowledge or any of the institutional knowledge that you have on your team it wasn't written by somebody on your team and so the generated code is not going to often not going to fit in with the project delete code everybody here probably has code in their projects that never gets touched by a user rarely gets touched by a user is nearly useless but for some reason or another it's expensive to delete it's expensive to change or whatever if you delete it you don't have to pay the maintenance costs how many features I'm sure everybody has these features we've got a lot of features that nobody uses we're getting rid of a huge set of features in our current app right now because people just the user didn't use it we added it nobody used these features of the story of multiple balances I think nobody used the features we're deleting it technical debt is an important one an important idea that people talk about I haven't seen a lot of cases where people really approach it in a great way technical debt for those of you that don't know is a phrase when we're cutting in we're first basically the cost or the consequences of poor design choices that are made today and the debt metaphor works because if you make a poor choice today you're going to pay for that poor choice continually in a growing way over the life of your project you can fix that poor choice that you made sometimes it's a quick hack to get things out the door sometimes it's a third party blocker this team over here this group is not giving you what you need to do your job so you have to put in a shim sometimes your understanding of the problem is a good enough gift because you don't have users in a different way than you thought the important thing to do is limit the amount of technical debt you're introducing in your project and also start paying off the interest start fixing those problems when your understanding improves go back and fix the code to match your update and understanding so one thing I like to do is adopt the Boy Scout rule the Boy Scout rule leaves things cleaner than you found every time you check out some old code that's already written and you notice something fix it I believe the rate passed in Rails 3 now I have a couple of custom things that I use to find fix-me notes in the code I write a lot of fix-me notes every time I'm introducing technical debt really easy to find listen to your tests if you have tests I hope everybody here has tests but your tests are going to tell you a lot of things about your code because your tests are using the code when you have tests your tests are using the code the production environment is using the code and that's a really important thing because then your code is decoupled by definition your slow tests are going to point out that you have a slow code your private tests are going to refer to a fragile code when you change something over here and something over here breaks that means that you've got some tight coupling that you need to resolve your tests are going to tell you more about your code they tell you more about your code than whether your code is correct or not they tell you a lot of different things about your code so don't get mad at your tests your tests are telling you important information the more it hurts the more important that information is like to be design patterns are really useful for having a shared vocabulary if I'm describing to you how I'm solving a problem and I can say we do this with that pattern that's a really great way to do it if you already are familiar with the same design patterns I don't have to explain the whole thing about the drop picture how to read the code for instance we cross this filter by sending them through a series of through the chain with a responsibility pattern if you're familiar with that pattern you know where to look it up you don't have to read all the code they're called patterns for a reason they exist in lots of software yours isn't a unique snowflake so you're going to find these places where you can adopt these patterns going to get improved communication you have to manage your dependencies coupling is really important coupling is between classes between everything in your code and the problems in ways that you might not have noticed is sometimes it's really easy to have your application coupled to a particular database most people who are using active record are already coupled to a SQL database or a database that is supported by active record if you have find by SQL or custom execute commands or whatever where you're using raw SQL you are probably also tightly coupled to whichever database you're using in production when people talk about coupling and software they're often not talking about how is my application tightly coupled to the database I'm using object-oriented design is going to be really important for this and this is the last thing I'd say on this this is an entire talk in itself but please learn about the object-oriented design principles the practices, the ASDP ebook by Alphabop is a great book it covers solid I'm working on an ebook which you can hit here you can sign up for information about it I would expect to be done in the next month or two and that'll tell you how to apply the solid principles to Rails having your maintainability and stuff like that so that's all I have to say on that we can do some I'd like to have more conversations about this over time so I already want to talk about this tell me if it's stupid find me afterwards you can find me on Twitter, GitHub, whatever and I'll see you in the next video thank you very much see you soon bye