(^148) 97 Things Every Programmer Should Know
The Road to Performance
Is Littered with Dirty
Code Bombs
Kirk Pepperdine
MORE OFTEN THAN NOT, performance tuning a system requires you to alter
code. When we need to alter code, every chunk that is overly complex or
highly coupled is a dirty code bomb lying in wait to derail the effort. The first
casualty of dirty code will be your schedule. If the way forward is smooth, it
will be easy to predict when you’ll finish. Unexpected encounters with dirty
code will make it very difficult to make a sane prediction.
Consider the case where you find an execution hot spot. The normal course
of action is to reduce the strength of the underlying algorithm. Let’s say you
respond to your manager’s request for an estimate with an answer of 3–4 hours.
As you apply the fix, you quickly realize that you’ve broken a dependent part.
Since closely related things are often necessarily coupled, this breakage is most
likely expected and accounted for. But what happens if fixing that dependency
results in other dependent parts breaking? Furthermore, the farther away the
dependency is from the origin, the less likely you are to recognize it as such and
account for it in your estimate. All of a sudden, your 3–4-hour estimate can eas-
ily balloon to 3–4 weeks. Often, this unexpected inflation in the schedule hap-
pens one or two days at a time. It is not uncommon to see “quick” refactorings
eventually taking several months to complete. In these instances, the damage to
the credibility and political capital of the responsible team will range from severe
to terminal. If only we had a tool to help us identify and measure this risk....
In fact, we have many ways of measuring and controlling the degree and depth
of coupling and complexity of our code. Software metrics can be used to count
the occurrences of specific features in our code. The values of these counts do