Chapter 74. The Road to Performance Is Littered with Dirty Code Bombs
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 ...
Get 97 Things Every Programmer Should Know now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.