Why work on performance? There are just two reasons.
|
|
I often write articles from the perspective of improvement - how to make your app faster, how to quicken up a page loadtime, or how to optimize a specific piece of code. Today, I thought I'd try to the opposite: what actions can you take to have the slowest Ruby on Rails web application on planet Earth? There are actually just five simple steps to follow.
Enter... Slow Rails CTO:
Track nothing
We're a Ruby on Rails shop, which means we ship a web application. How do people interact with web applications? Well, they load them their in their browser, look at all the pretty pixels you painted, and then click things and enter text.
That means that the user experience - the actual experience of input, delay, output controlled by your code - 100% takes place in your client browsers.
But, we're not going to track that.
Using "real user monitoring" tools like Datadog RUM or Raygun is lame. I mean, you write Ruby, and Ruby doesn't run in the browser, so why would you want performance information from the browser, right? And I heard the browser has this icky built-in language called JavaScript, and I hate Javascript, so let's keep it out of sight and out of mind and just avoid tracking it altogether.
There are a lot of things, actually, that can impact the customer's experience other than server reponse times. Request queue times are one: how long requests spend waiting for a free Unicorn or Puma process. This time can be tracked by most APMs, and it takes about 10 minutes and one pull request to set up, but who has time for that, honestly? Better not to track it all. Besides, it's fine most of the time, right? If customers notice a problem, they'll complain and send emails or give you a call, which is sort of like the best (and cheapest!) monitoring you can have!
If you're going to track anything at all, keep it nice and simple and only track Rails server response times. These usually average about 300 milliseconds, which is probably less than 10% of the average page load experience, but as we all know, it's the best part. The other 90% is someone else's problem - probably the frontend engineers. We do have those, right?
Don't use any tools
Performance tools are lame. Really, the site should just be fast by default, so installing any tooling that helps us debug performance issues is just unnecessary. I don't like being reminded about how slow our site is all the time, so it's better if we just don't display any numbers or information to developers at all.
We could use rack-mini-profiler.
We could use singed.
We could use benchmark-ips.
But that all requires actually learning to use those tools. And learning, as we all know, is expensive and takes away from time spent...
Features above all else
... building features. Features are what make the world go 'round, and they're what makes this company money. So, we're going to spend as much time as we can shipping new things to the customer, and maybe if there's time afterward, we can work on tidying it all up.
Since we're not tracking how quickly or slowly our pages load, we have no idea whether or not the features we're shipping are actually too slow to be usable or not. But that's fine - it's fast on our machines and QA hasn't complained yet. If customers complain, I'm sure it will be just one or two of them.
I think I heard someone say once to "move fast and break stuff". So, let's move fast! Performance work doesn't make us more money, so it will have to wait.
Just ship performance improvements, don't measure them
Hmmm, okay, a lot of customers are complaining now. What should we do?
We'll put a handful of our best engineers on it for... 4 weeks? Goodness no, that's way too long to not be working on features. Let's call it a week. Anyway, while they're working on performance for a week, what will they be doing?
Well, whatever they feel like, of course! Senior engineers are smart, that's what we pay them for. And so, they have an innate sense (or at least some experience) about what the bottlenecks in our application are. They don't need to look at dashboard after dashboard. They just need to get in there and start optimizing.
I mean, it's not like we have any dashboards they can look at, anyway. And even if we did, we wouldn't know how to interpret them.
When they have a performance fix, they'll just deploy it and move on. No need to check to see if it actually made things faster or not. That will take much too long. We need to move fast and break stuff, remember? Instead, we'll just ship as many optimizations as we can think of in one week and that will definitely take care of this problem.
Don't learn anything new
Well, that didn't work. We let our best people work on whatever performance optimizations they felt like and people are still complaining. What a waste of time! I knew we shouldn't have taken a week off from the important stuff - features - to let our engineers waste their time on a bunch of geekery!
Financial results are headed in the wrong direction, so it's time to take charge of this situation. It calls for bold thinking, and quick action. So, it's time to cancel everyone's learning budget. Books, conferences, workshops: no more of that! We've been spending like drunken sailors out here, and we need to cut things down to the minimum.
Anyway, the site is fast enough. I don't care if a few customers complain. What's that - our churn rate is down and our user engagement is decreasing? Hm, well, someone call a meeting right away! I want all hands on deck.
Ring any bells?
Ok, Nate again.
I hope that was a fun story. While this story may have sounded like PHP_CEO, the truth is that I've seen all of these mistakes being made at a client company at one point or another. If any of these points resonated with you, take a step back and think about how your organization got here: what do we value? What is our culture? What incentives have we created that led to this outcome?
Until next time,
-Nate
|
|
|
|