Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell and in today's episode we're going to be talking about avoiding over optimization by using a performance budget. This is actually going to be a two part episode. You'll hear this part today and the next part in the next episode of Developer Tea. Of course if you don't want to miss out on that make sure you subscribe to the podcast and whatever podcasting app you use. So let's talk about how to avoid over optimization by using a performance budget. That's a long title over optimization by using a performance budget. If you've never heard of a performance budget I recommend you Google it. I'm not the first one to talk about a performance budget by any stretch but it's a really interesting idea and I want to talk about how you might approach this concept in your projects. Optimization of code is a huge part of a developer's day to day job. We're going to talk about optimization but specifically we're going to talk about over optimization in today's episode. Over optimization happens when you do optimization that isn't really worth your time. It's not really worth the investment of your resources to perform that optimization. Today's episode is sponsored by RoeBar. With RoeBar you get the context, insights and control you need to find and fix bugs faster. We'll talk about RoeBar more later on in today's episode and specifically about an offer that RoeBar has for you. I'm using RoeBar on a project and I think it's fantastic. We'll talk more about what RoeBar has to offer to Developer Tea listeners but first let's talk about over optimization. Or something ships to a user and when I say user I mean either a person or a computer before you ship your code to an end user you want to make sure that you have that code properly optimized. Optimization occurs both in ongoing code. So on your day to day as you are coding you should be using optimal methods when possible and avoiding things like memory leaks for example but it also can occur in a refactoring situation and most of what we're going to talk today is probably going to apply to the refactoring more than it is in the ongoing optimization. When optimizing your code it can be difficult to determine just how much optimization is necessary. For example we know that our code benefits from being optimized in speed is a priority but what level of investment in time to optimize is worth it. It can be difficult to answer this question because on the one hand anything we do in optimization pays back over the life of the product. So it's easy to think that means any optimization is good and this is the trap that developers very often fall into. We think that any optimization is good so it's always worth our time to start optimizing. However on the other hand there is a level of optimization that has little to no return on investment. Little to no return on investment. This is incredibly important to your boss. This is incredibly important to you if you're a business owner. You want a high return on your investments. You want to be able to spend your time and get value out of that spent time. As we said previously the optimization will pay us back over the life of the product but let's imagine for example that the life of the product is very short. Say the product is only being used a few times like a utility script or maybe an administrative reporting interface where you run a bunch of queries and it just gives you a report on a quarterly basis. What's possible and perhaps even likely at spending time optimizing that code is going to have a low return on investment in comparison to optimizing code that is used much more often. That doesn't mean though that we should write a responsible code just because it won't be running over and over into the future. How do we determine what level of optimization is sufficient? This is a pretty complex situation it seems like. Today I'm going to teach you how to create a performance budget. I'm not going to give you math figures and I'm not going to give you a exact equation to use. Instead I'm going to give you the way that you think about a performance budget. We're going to talk about five things that you need to understand. You need to think about when you are creating your performance budget. We're going to go through three of them today and then the next two in the next episode of Developer Tea. Number one, you need to ask yourself what is the usage rate over time of this particular feature or piece of code? What is the usage rate over time of this particular feature or product, piece of code? Why do we want to think about this? The higher the usage rate of your piece of code, in other words, the more times that piece of code is run, the higher the leverage of each of your optimizations in the long run. Let me say that again. The higher the usage rate, in other words, the higher the number of times somebody or something like a computer runs your code over time, the higher the leverage each of your optimizations has in the long run. If you optimize and you optimize for, let's say, one second increase in speed, it's one second. If that code is running only once per day, then you gain one second of benefit per day. It's really simple math here. One second of benefit per day. If you have that code running five times per day, then obviously it's five times more per day. If you are growing at a rate of five executions per day, let's say five times that your code is running today, it's running 10 times tomorrow, and 15 times, or maybe even 20 times, the next day, if you're growing at an exponential rate, or even if you're growing at a linear rate, then your return on that investment will grow at an exponential rate. This is why it's so important to determine the usage rate of your particular piece of code over time. Determine the usage rate of that piece of code over time. The corollary to this number two is what is the actual lifetime of the code? If you're going to change the code significantly in the near future, if you're going to gut the system, it may not necessarily make sense to optimize it now. This is especially true for projects that are only used one time. Property scripts are perfect example, do not spend time over optimizing your utility scripts. They're only going to run once, and they only need to meet the minimum requirements. We're going to talk about minimum optimizations in just a second. If the product is likely to scale and grow in the future, and you don't have any shutdown planned, be certain you're setting yourself up for that optimization in the future. However, the problems you face at scale are probably not the most valuable problems to solve in the early phases of a product. We don't want to over optimize for that future scale before we need to. We aren't going to talk about product planning in today's episode, but be certain that you understand the future of your product, that you have a plan for the future of your product, and take that into consideration as you go through refactoring for optimization. There is not much benefit to refactoring today if the code is not going to run tomorrow. Think about that for a second. There's not much benefit in refactoring today if the code is not going to run tomorrow. Of course, there are some caveats to this. It may be that you're going to use this code in a different project, or it may be that you're trying to learn how to perform optimizations. Those are certainly fine reasons to go through the process of optimization, but if you are trying to create a performance budget, if that is your goal, and if you're listening to this episode, then presumably that is your goal. If you are interested in creating a performance budget, this is the way you should be thinking about your optimizations. If your optimization doesn't actually create value in the future, then it doesn't make much sense to perform that optimization at all. It doesn't make much sense to create code for tomorrow if it's not going to run tomorrow. We're going to take a quick sponsor break, and we're going to talk about minimum optimizations. Speaking of optimizations, today's episode is sponsored by Rollbar. With Rollbar, you can put errors in their place. Dealing with errors absolutely sucks. Lying on users to report the errors to you or digging through logs trying to debug the issues. These can be difficult things. Sometimes it's even hard to find where the logs are. Rollbar works with all major languages and frameworks to eliminate this problem altogether. You can start tracking production errors and deployments in eight minutes or less. I actually set up Rollbar entirely for free, and I got it sending messages to a Slack channel for a project that I'm working on. I did it in just a few minutes. It's incredibly easy to get started. You can start tracking production errors and deployments in eight minutes or less. You integrate Rollbar into existing development workflows. You can send alerts to Slack or HipChat, or you can create issues in GitHub or Gira, Asana, Pivotal Tracker, pretty much everything that you're probably using Rollbar most likely supports. Some of Rollbar's customers include Heroku, Twilio, Kayak, Instacart, Zendesk, Twitch. Do we need to continue? Hopefully you can see that Rollbar has a great customer list and a good history, a good track record. If their track record was not enough, Rollbar is providing Developer Tealisteners with a special offer. If you go to the link in the show notes, which is rollbar.com slash Developer Tea, if you go to that link, you can get the bootstrap plan free for 90 days. That's three months of error tracking. That's long enough to get your startup up and going. That's 300,000 errors that you get to track for free. Go and check it out, rollbar.com slash Developer Tea. I'm using it. I suggest you check it out if you are tired of trying to track down errors on your own. Rollbar is a great option. Of course, you can find that link in the show notes at spec.fm. We're talking about avoiding over optimization by creating a performance budget. We're talking specifically about the five things that you need to be thinking about when you're creating your performance budget. We're covering the first three today and in the next episode, we're going to cover the next two and we'll talk about actually creating that budget. Number one was determine the usage rate over time of that particular feature that you are considering optimizing. Number two is determine the lifetime of the code that you're considering optimizing. With those two things, you can determine the value of that optimization. If you combine numbers one and two, you determine the value of that optimization. You're making an educated guess about how valuable that optimization is. Number three, you need to determine the minimum optimizations necessary. You need to determine the minimum optimizations necessary. There's a minimum level of optimization that is necessary for any feature. Every feature has a minimum optimization. If a piece of code, for example, is supposed to be run on an hourly basis and the task that that code is completing needs to take five minutes, then the absolute minimum viable optimization of the running time for that piece of code is five minutes. Of course, there are other optimization minimums that should be taken into account, such as the file size or the readability of the text. Once again, the minimums for your particular use case will vary, but determining these minimums will help guide your optimization strategy. Obviously, if you have a cron job that's running that takes an hour to generate a report, it's going to be a very different optimization strategy than loading a web page, for example. You want to load a web page in less than a second. These are two very different minimum optimizations. Creating your performance budget uses these minimum optimizations as the baseline. We will talk more about creating your performance budget in the next episode of Developer Tea. Thank you so much for listening today. Thank you again to Rollbar for sponsoring today's episode. Tracking errors is not a negotiable thing. You have to track errors if you have a project that is running in the wild. There's no way around that. And Rollbar makes that so much easier for you. Go and check it out, rollbar.com slash Developer Tea. Make sure you subscribe to Developer Teain whatever podcasting app you use so that you ensure that you're not going to miss out on future episodes of the show, particularly part two of today's episode. Thank you so much again for listening to Developer Tea. You can find all the show notes for this episode and you can listen to every other episode of Developer Teaat spec.fm. I also want to encourage you to go and check out the other shows on spec.fm. If you're a designer or developer or a data scientist, there are shows for you to level up in your career. Go and check it out spec.fm. Thanks so much and until next time, enjoy your tea.