97 Things Every Programmer Should Know

Chapter 74. 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 easily balloon to 3–4 weeks. Often, this unexpected inflation in the schedule happens one or two days at a time. It is not uncommon to see “quick” refactorings eventually ...