When Premature Optimization Makes Sense

We’ve all been told stay away from prematurely optimizing our code. Whether you’re building for the enterprise or trying to get your first MVP out, chances are you shouldn’t spend too much time tweaking your code for marginal efficiency gains. As Donald Knuth describes in his 1974 book, Computer Programming as an Art, “worrying about, the speed of noncritical parts of their programs, and these attempts at efficiently actually have a strong negative impact….”. But how can we determine what will have a strong negative impact further on down the line? In this write-up, I will detail a small decision I made within my latest SaaS project Novelty, a social media marketing platform for Etsy sellers. The decision to fight premature optimization. And when I speak of optimization I mean it within the business context of getting a product to market, rather than algorithmic performance gains.

“The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.”

— Computer Programming as an Art (1974) Donald Knuth

Product Hunt’s Twitter account shared this meme the other day and it made me chuckle.

I chuckled because the struggle is real! Often times we start coding without giving any thought to what we’re about to build. Which is usually fine! We’ve hopefully spent a few cycles documenting and designing our product with wireframes, flowcharts and the like before we’ve sat down to hack. Now is simply time to implement. Yet, developers often need to consider efficiency and often times it’s too late.

There are certain things developers need to optimize, for example, if your building a web application you should consider optimizing server-side caching sooner rather than later.

Let’s say your building a banking app. When you request an account balance from the server, a database query is made. That result should then be serialized and stored in a database cache such as Redis. The next time a user needs access to their account balance, you can quickly “get(id)” this data. The cache would only be invalid if a deposit or withdrawal occurred. You could even pre-fill this cache when a deposit or withdrawal occurred. They call this “warming” the cache. The idea here is that this type of optimization would dramatically affect the user’s experience thus giving the appearance of a snappy application. This is what users need. This is what your app needs so it makes sense to setup your database caching as soon as possible.

A second, less exciting example could be optimizing global resources.

When building out my MVP for Novelty, I had to cut corners in order to get to market quickly. There were obvious things I missed and other things I intentionally left out of version one. With this being my first web application written in ReactJS, there was some confusion about the way React handled global resources, but I’ll leave that for another write-up. I used Facebook’s JavaScript API within my app and the client needs to access the application ID. I started off with one Facebook ID, which quickly became two after I deployed to product and needed another “test” ID. Facebook gives you a way to create Test Apps to make the process a bit easier.

I quickly realized that now I had to remember to switch out the product app ID with the test one every time I deployed to production servers. This was extremely important to remember! I thought to myself, how can I make this easier on myself? Well, we could build out a REST endpoint to serve the correct app ID depending on the servers environment variables, that way we wouldn’t have to worry about changing the app ID before we deployed. To optimize or not to optimize, tiz the question….

I thought about it for a while and decided not to do it. I will continue to switch the app ID before each deployment, even if it doesn’t make much sense. I will add that optimization to my ever-growing list and get to it when I get to it. The point being is there are more important things to worry about like getting customers and building out features that they care about. I, on the other hand, can suffer as my product gets better.

Thanks for reading! My name is Alex, Founder/Developer of Novelty, a social media marketing platform for Etsy sellers. I write about my journey as a first-time founder. Feel free to reach out!

Image Credit: www.developers.facebook.com

Originally published at www.alexdaro.com on November 6, 2017.