The Road to Performance Is Littered with Dirty Code Bombs

From WikiContent

(Difference between revisions)
Jump to: navigation, search
Current revision (05:57, 7 July 2009) (edit) (undo)
 
(14 intermediate revisions not shown.)
Line 1: Line 1:
-
Performance problems are a direct result of how you coded your application to use the available hardware. While one can sometimes solve the problem by adding more hardware, quite often the best or only solution is to alter code. By starting down that path you've just agreed to take on all the risk that comes when you start to change code. Furthermore, the quality of the code will have an inverse affect on your ability to estimate how long it will take to finish the recoding.
+
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 laying 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.
-
Take the case where you find an execution hotspot in the application. You then proceed to reduce the strength of the underlying algorithm and in the process you break some a dependent part. You then are required to fix the dependency. If in that process of fixing the dependency you happen to break one or more other dependent parts, once again you will be forced to fix those also. While you may have accounted for some of the dependencies, if the code is highly coupled you may have missed a few which will result in an under-estimation of the amount of work needed to get the job done. In this case we have a clear definition for loose coupling and a dependency. So why can't we have a tool count the violations and report back to us? Such a count should help us understand our risk to schedule.
+
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? Further more, 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 1 or 2 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 the degree and depth of couplings in an application. Included in the list are Law of Demeter, Coupling between Objects (CBO), fan in, fan out, efferent and afferent couplings, depth of hierarchy and so on. These metrics describe features in our code that we can enumerate using a metrics tool. With a little experience, we can infer code quality by inspecting the magnitude of the counts. Consider fan out for example. Fan out is defined as the number of classes that is dependent upon a class of interest. Think of it as a count of the number of classes that require the class of interest to be compiled before it can be compiled. That number represents the fan out value for the class of interest. If for every class in an application this value is small, you'd conclude that the application was loosely coupled. The upside is that I can refactor with minimal risk that my breakages will also fan out.
+
In fact we have many ways of measuring and controlling the degree and depth of couplings 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 correlate with code quality. Two of the number of metrics that measure couplings are fan-in and fan-out. Consider fan-out: It is defined as the number of classes referenced either directly or indirectly from a class of interest. You can think of this as a count of all the classes that must be compiled before your class can be compiled. Fan-in, on the other hand, is a count of all classes that depend upon the class of interest. Knowing fan-out and fan-in we can calculate an instability factor using ''I = f<sub>o</sub> / (f<sub>i</sub> + f<sub>o</sub>)''. As ''I'' approaches 0, the package becomes more stable. As ''I'' approaches 1, the package becomes unstable. Packages that are stable are low risk targets for recoding whereas unstable packages are more likely to be filled with dirty code bombs. The goal in refactoring is to move ''I'' closer to 0.
-
Though the discussion has focused on measuring couplings, it could have easily focused on complexity, vocabulary and volume, cohesion and a host of other metrics. Each of these metrics is a measure of code quality and hence a way to determine risk to schedule should you have to touch the code.
+
When using metrics one must remember that they are only rules of thumb. Purely on maths we can see that increasing ''f<sub>i</sub>'' without changing ''f<sub>o</sub>'' will move ''I'' closer to 0. There is, however, a downside to a very large fan-in value in that these class will be more difficult to alter without breaking dependents. Also, without addressing fan-out you're not really reducing your risks so some balance must be applied.
-
We all believe that we write good code. That said, the truth is as close as a good metrics tool. And if you don’t like what the metrics tool is telling you, try a good dose of Uncle Bob’s book, Clean Code.
+
One downside to software metrics is that the huge array of numbers that metrics tools produce can be intimidating to the uninitiated. That said, software metrics can be a powerful tool in our fight for clean code. They can help us to identify and eliminate dirty code bombs before they are a serious risk to a performance tuning exercise.
By [[Kirk Pepperdine]]
By [[Kirk Pepperdine]]
-
This work is licensed under a
+
This work is licensed under a [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
-
[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
+
Back to [[97 Things Every Programmer Should Know]] home page
Back to [[97 Things Every Programmer Should Know]] home page

Current revision

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 laying 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? Further more, 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 1 or 2 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 couplings 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 correlate with code quality. Two of the number of metrics that measure couplings are fan-in and fan-out. Consider fan-out: It is defined as the number of classes referenced either directly or indirectly from a class of interest. You can think of this as a count of all the classes that must be compiled before your class can be compiled. Fan-in, on the other hand, is a count of all classes that depend upon the class of interest. Knowing fan-out and fan-in we can calculate an instability factor using I = fo / (fi + fo). As I approaches 0, the package becomes more stable. As I approaches 1, the package becomes unstable. Packages that are stable are low risk targets for recoding whereas unstable packages are more likely to be filled with dirty code bombs. The goal in refactoring is to move I closer to 0.

When using metrics one must remember that they are only rules of thumb. Purely on maths we can see that increasing fi without changing fo will move I closer to 0. There is, however, a downside to a very large fan-in value in that these class will be more difficult to alter without breaking dependents. Also, without addressing fan-out you're not really reducing your risks so some balance must be applied.

One downside to software metrics is that the huge array of numbers that metrics tools produce can be intimidating to the uninitiated. That said, software metrics can be a powerful tool in our fight for clean code. They can help us to identify and eliminate dirty code bombs before they are a serious risk to a performance tuning exercise.


By Kirk Pepperdine

This work is licensed under a Creative Commons Attribution 3


Back to 97 Things Every Programmer Should Know home page

Personal tools