Article development led by
The operations side of the story.
BY THOMAS A. LIMONCELLI
A FRIEND WAS asked the following question during a
job interview: What is the fastest algorithm to find the
largest number in an unsorted array?
The catch, of course, is that the data is unsorted.
Because of that, each item must be examined; thus,
the best algorithm would require O(N) comparisons,
where N is the number of elements. Any computer
scientist knows this. For that reason, the fastest
algorithm will be a linear search through the list.
End of story.
All the computer scientists may leave the room now.
Are all the computer scientists gone?
Now let’s talk about the operational answer to
System administrators (DevOps engineers or SREs or whatever your title)
must deal with the operational aspects
of computation, not just the theoretical aspects. Operations is where the
rubber hits the road. As a result, operations people see things from a different
perspective and can realize opportunities outside of the basic O() analysis.
Let’s look at the operational aspects of the problem of trying to improve something that is theoretically
1. Don’t Optimize Code
that is Fast Enough
The first optimization comes from deciding to optimize time and not the
algorithm itself. First, ask whether the
code is fast enough already. If it is, you
can optimize your time by not optimizing this code at all. This requires a definition of fast enough.
Suppose 200ms and under is fast
enough. Anything that takes less than
200ms is perceived to be instantaneous by the human brain. Therefore,
any algorithm that can complete the
task in less than 200ms is usually good
enough for interactive software.
Donald Knuth famously wrote that
premature optimization is the root of
all evil. Optimized solutions are usually
more complex than the solutions they
replace; therefore, you risk introducing
bugs into the system. A bird in hand is
worth two in the bush. Why add complexity when you don’t have to?
My biggest concern with premature
optimization is it is a distraction from
other, more important work. Your time
is precious and finite. Time spent on
a premature optimization is time that
could be spent on more important work.
Prioritizing your work is not about
deciding in what order you will do the
items on your to-do list. Rather, it is
deciding which items on your to-do list
will be intentionally dropped on the
floor. I have 100 things I would like to
do this week. I am going to complete
only about 10 of them. How I prioritize
my work determines which 90 tasks
won’t get done. I repeat this process ev-