In this modern age of ours faster is better. If you want to win the market, you have to be faster. Users drop off your Web site if your site is too slow. If you want to win a bike race, you have to go faster. You’ll drop off the peloton (principal group of cyclists in a bike race, riders in a group save energy by riding close) and lose the race for sure if you are not fast enough.
Once again I discovered to my surprise that the same principles apply to both cycling and software. Find the weakest link, and fix it.
In SharedBook where we use software to create books with rich content and photos, our weakest link was the photos. Fetching photos from different sites can take a lot of time. Processing those photos within the server is a time consuming task (not to mention CPU and memory). How do you improve that?
Well, Saffi, the head of our architecture team, came up with a simple and effective concept: caching. Once we fetch the photo for the first time, we cache it and use it again and again. We even cache the different versions of the processed photo internally, thus saving ourselves more processing time. How do you introduce this into an existing system? You’ve probably guessed it: very carefully, with lots of patience. Refactor your codebase, one step at a time, and move to the next step.
In cycling, my weakest link was making turns. Especially those S shaped turns. How do you improve that? You’ve probably guessed it again: very carefully, and with lots of patience. Practice turns again and again, one step at a time, and move to the next step (sharper turns, faster turns).
In SharedBook the caching saves us a lot of time, making our book creation process much faster.
In cycling, better cornering saves me a lot of time, allowing me to stick with the peloton and go much faster.
And what’s the next step? Going even faster of course!