Get Out of Your Silo
Before discussing the remaining optimizations, let’s discuss the value of
thinking more globally about the problem. Many optimizations come from
end-to-end thinking. Rather than optimizing the code itself, we should look
at the entire system for inspiration.
To do this requires something scary:
talking to people. Now, I understand
that a lot of us go into this business because we like machines more than people, but the reality is that operations is
a team sport.
Sadly, often the operations team is
put in a silo, expected to work issues
out on their own without the benefit of
talking to the people who created the
system. This stems from the days when
one company created software and sold
it on floppy disks. The operations people were in a different silo from the developers because they were literally in
a different company. System administrators’ only access to developers at the
other company was through customer
support, whose job it was to insulate
developers from talking to customers
directly. If that ever did happen, it was
called an escalation, an industry term
that means that a customer accidentally got the support he or she paid for. It
is something that the software industry
tries to prevent at all costs.
Most (or at least a growing proportion
of) IT operations, however, deal with
software that is developed in-house. In
that situation there is very little excuse
to have developers and operations in
separate silos. In fact, they should talk
to each other and collaborate. There
should be a name for this kind of collaboration between developers and operations ... and there is: DevOps.
If your developers and operations
teams are still siloed away from each
other, then your business model hasn’t
changed since software was sold on
floppy disks. This is ironic since your
company probably didn’t exist when
floppy disks were in use. What’s wrong
with this picture?
Get out of your silo and talk to peo-
ple. Take a walk down the hallway and
introduce yourself to the developers in
your company. Have lunch with them.
Indulge in your favorite after-work bev-
erage together. If you are a manager
who requires operations and devel-
opers to communicate only through
“proper channels” involving commit-
tees and product management chains,
get out of their way.
Once operations has forged a relationship with developers, it is easier to
ask important questions, such as: How
is the data used? What is it needed for
This kind of social collaboration
is required to develop the end-to-end
thinking that makes it possible to
optimize code, processes, and organizations. Every system has a bottleneck. If you optimize upstream of the
bottleneck, you are simply increasing
the size of the backlog waiting at the
bottleneck. If you optimize downstream of the bottleneck, you are adding capacity to part of a system that
is starved for work. If you stay within
your silo, you’ll never know enough to
identify the actual bottleneck.
Getting out of your silo opens the
door to optimizations such as our last
7. Use a “Good Enough”
Is the maximum value specifically
needed, or is an estimate good enough?
Perhaps the calculation can be
Often an estimate is sufficient, and
there are many creative ways to calculate one. Perhaps the max value from
the previous dataset is good enough.
Perhaps the max value is being
used to preallocate memory or other
resources. Does this process really
need to be fine-tuned every time the
program runs? Might it be sufficient
to adjust the allocations only occasionally—perhaps in response to resource
monitoring or performance statistics?
If you are dealing with a small
amount of data (using the earlier definition of small), perhaps preallocating
resources is overkill. If you are dealing
with large amounts of data, perhaps
preallocating resources is unsustainable and needs to be reengineered before it becomes dangerous.
8. Seek Inspiration from
the Upstream Processes
Sometimes we can get a different perspective by examining the inputs.
Where is the data coming from?
I once observed a situation where
a developer was complaining that an
the code itself,
we should look
at the entire system