http://commons.oreilly.com/wiki/index.php?title=The_Road_to_Performance_Is_Littered_with_Dirty_Code_Bombs&action=history&feed=atomThe Road to Performance Is Littered with Dirty Code Bombs - Revision history2013-05-20T16:36:51ZRevision history for this page on the wikiMediaWiki 1.11.0http://commons.oreilly.com/wiki/index.php?title=The_Road_to_Performance_Is_Littered_with_Dirty_Code_Bombs&diff=24655&oldid=prevKcpeppe at 05:57, 7 July 20092009-07-07T05:57:21Z<p></p>
<table style="background-color: white; color:black;">
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr>
<td colspan='2' style="background-color: white; color:black;">←Older revision</td>
<td colspan='2' style="background-color: white; color:black;">Revision as of 05:57, 7 July 2009</td>
</tr>
<tr><td colspan="2" class="diff-lineno">Line 3:</td>
<td colspan="2" class="diff-lineno">Line 3:</td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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.</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>In fact we have many ways of measuring and controlling the degree and depth of couplings and complexity of our code. <del style="color: red; font-weight: bold; text-decoration: none;">The fundamental </del>metrics <del style="color: red; font-weight: bold; text-decoration: none;">concerning </del>the <del style="color: red; font-weight: bold; text-decoration: none;">level </del>of <del style="color: red; font-weight: bold; text-decoration: none;">coupling are in terms of fan-in and fan-out. These metrics describe </del>features in our code <del style="color: red; font-weight: bold; text-decoration: none;">that we can look for and count</del>. <del style="color: red; font-weight: bold; text-decoration: none;">Moreover, the magnitudes </del>of these counts do correlate with code quality. 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.</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>In fact we have many ways of measuring and controlling the degree and depth of couplings and complexity of our code. <ins style="color: red; font-weight: bold; text-decoration: none;">Software </ins>metrics <ins style="color: red; font-weight: bold; text-decoration: none;">can be used to count </ins>the <ins style="color: red; font-weight: bold; text-decoration: none;">occurrences </ins>of <ins style="color: red; font-weight: bold; text-decoration: none;">specific </ins>features in our code. <ins style="color: red; font-weight: bold; text-decoration: none;">The values </ins>of these counts do correlate with code quality<ins style="color: red; font-weight: bold; text-decoration: none;">. Two of the number of metrics that measure couplings are fan-in and fan-out</ins>. 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.</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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.</div></td></tr>
</table>Kcpeppehttp://commons.oreilly.com/wiki/index.php?title=The_Road_to_Performance_Is_Littered_with_Dirty_Code_Bombs&diff=24645&oldid=prevKevlin at 21:39, 6 July 20092009-07-06T21:39:41Z<p></p>
<table style="background-color: white; color:black;">
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr>
<td colspan='2' style="background-color: white; color:black;">←Older revision</td>
<td colspan='2' style="background-color: white; color:black;">Revision as of 21:39, 6 July 2009</td>
</tr>
<tr><td colspan="2" class="diff-lineno">Line 3:</td>
<td colspan="2" class="diff-lineno">Line 3:</td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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.</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>In fact we have many ways of measuring and <del style="color: red; font-weight: bold; text-decoration: none;">contorlling </del>the degree and depth of couplings and complexity of our code. <del style="color: red; font-weight: bold; text-decoration: none;">Metrics that measure </del>the level of coupling <del style="color: red; font-weight: bold; text-decoration: none;">include Law </del>of <del style="color: red; font-weight: bold; text-decoration: none;">Demeter, </del>fan-in and fan-out. These metrics describe features in our code that we can look for and count. Moreover, the magnitudes of these counts do correlate with code quality. Consider <del style="color: red; font-weight: bold; text-decoration: none;">the </del>fan-out <del style="color: red; font-weight: bold; text-decoration: none;">metric. </del>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. <del style="color: red; font-weight: bold; text-decoration: none;">The metric fan</del>-in 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 = <del style="color: red; font-weight: bold; text-decoration: none;">fo </del>/ (<del style="color: red; font-weight: bold; text-decoration: none;">fi </del>+ <del style="color: red; font-weight: bold; text-decoration: none;">fo</del>). <del style="color: red; font-weight: bold; text-decoration: none;">If </del>I <del style="color: red; font-weight: bold; text-decoration: none;">is </del>0, the package <del style="color: red; font-weight: bold; text-decoration: none;">is very </del>stable. <del style="color: red; font-weight: bold; text-decoration: none;">If </del>I <del style="color: red; font-weight: bold; text-decoration: none;">is </del>1, the package <del style="color: red; font-weight: bold; text-decoration: none;">is very </del>unstable. Packages that are stable are low risk targets for recoding <del style="color: red; font-weight: bold; text-decoration: none;">where as </del>unstable packages are filled with dirty code bombs. The goal in refactoring is to move I closer to 0.</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>In fact we have many ways of measuring and <ins style="color: red; font-weight: bold; text-decoration: none;">controlling </ins>the degree and depth of couplings and complexity of our code. <ins style="color: red; font-weight: bold; text-decoration: none;">The fundamental metrics concerning </ins>the level of coupling <ins style="color: red; font-weight: bold; text-decoration: none;">are in terms </ins>of fan-in and fan-out. These metrics describe features in our code that we can look for and count. Moreover, the magnitudes of these counts do correlate with code quality. Consider fan-out<ins style="color: red; font-weight: bold; text-decoration: none;">: </ins>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. <ins style="color: red; font-weight: bold; text-decoration: none;">Fan</ins>-in<ins style="color: red; font-weight: bold; text-decoration: none;">, on the other hand, </ins>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 <ins style="color: red; font-weight: bold; text-decoration: none;">''</ins>I = <ins style="color: red; font-weight: bold; text-decoration: none;">f<sub>o</sub> </ins>/ (<ins style="color: red; font-weight: bold; text-decoration: none;">f<sub>i</sub> </ins>+ <ins style="color: red; font-weight: bold; text-decoration: none;">f<sub>o</sub></ins>)<ins style="color: red; font-weight: bold; text-decoration: none;">''</ins>. <ins style="color: red; font-weight: bold; text-decoration: none;">As ''</ins>I<ins style="color: red; font-weight: bold; text-decoration: none;">'' approaches </ins>0, the package <ins style="color: red; font-weight: bold; text-decoration: none;">becomes more </ins>stable. <ins style="color: red; font-weight: bold; text-decoration: none;">As ''</ins>I<ins style="color: red; font-weight: bold; text-decoration: none;">'' approaches </ins>1, the package <ins style="color: red; font-weight: bold; text-decoration: none;">becomes </ins>unstable. Packages that are stable are low risk targets for recoding <ins style="color: red; font-weight: bold; text-decoration: none;">whereas </ins>unstable packages are <ins style="color: red; font-weight: bold; text-decoration: none;">more likely to be </ins>filled with dirty code bombs. The goal in refactoring is to move <ins style="color: red; font-weight: bold; text-decoration: none;">''</ins>I<ins style="color: red; font-weight: bold; text-decoration: none;">'' </ins>closer to 0.</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>When using metrics one must remember that they are only rules of thumb. Purely on maths we can see that increasing <del style="color: red; font-weight: bold; text-decoration: none;">fi </del>without changing <del style="color: red; font-weight: bold; text-decoration: none;">fo </del>will move I closer to 0. <del style="color: red; font-weight: bold; text-decoration: none;">However there </del>is 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.</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>When using metrics one must remember that they are only rules of thumb. Purely on maths we can see that increasing <ins style="color: red; font-weight: bold; text-decoration: none;">''f<sub>i</sub>'' </ins>without changing <ins style="color: red; font-weight: bold; text-decoration: none;">''f<sub>o</sub>'' </ins>will move <ins style="color: red; font-weight: bold; text-decoration: none;">''</ins>I<ins style="color: red; font-weight: bold; text-decoration: none;">'' </ins>closer to 0. <ins style="color: red; font-weight: bold; text-decoration: none;">There </ins>is<ins style="color: red; font-weight: bold; text-decoration: none;">, however, </ins>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.</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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. </div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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. </div></td></tr>
</table>Kevlinhttp://commons.oreilly.com/wiki/index.php?title=The_Road_to_Performance_Is_Littered_with_Dirty_Code_Bombs&diff=24632&oldid=prevKcpeppe at 19:27, 6 July 20092009-07-06T19:27:30Z<p></p>
<table style="background-color: white; color:black;">
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr>
<td colspan='2' style="background-color: white; color:black;">←Older revision</td>
<td colspan='2' style="background-color: white; color:black;">Revision as of 19:27, 6 July 2009</td>
</tr>
<tr><td colspan="2" class="diff-lineno">Line 3:</td>
<td colspan="2" class="diff-lineno">Line 3:</td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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.</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>In fact we have many ways of measuring and contorlling the degree and depth of couplings and complexity of our code. <del style="color: red; font-weight: bold; text-decoration: none;">Included are </del>the Law of Demeter<del style="color: red; font-weight: bold; text-decoration: none;">, Coupling between Objects (CBO)</del>, fan in<del style="color: red; font-weight: bold; text-decoration: none;">, </del>fan out <del style="color: red; font-weight: bold; text-decoration: none;">which create efferent and afferent couplings and so on</del>. These metrics describe features in our code that we can look for and count. Moreover, the magnitudes of these counts do correlate with code quality. Consider the fan-out metric <del style="color: red; font-weight: bold; text-decoration: none;">for example where couplings "fan out" from </del>the 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. <del style="color: red; font-weight: bold; text-decoration: none;">Dependencies all "</del>fan in<del style="color: red; font-weight: bold; text-decoration: none;">" from </del>classes that <del style="color: red; font-weight: bold; text-decoration: none;">reference your </del>class. <del style="color: red; font-weight: bold; text-decoration: none;">If for every class </del>in an <del style="color: red; font-weight: bold; text-decoration: none;">application these counts are small</del>, <del style="color: red; font-weight: bold; text-decoration: none;">you can safely conclude </del>that <del style="color: red; font-weight: bold; text-decoration: none;">couplings </del>are <del style="color: red; font-weight: bold; text-decoration: none;">shallow and, therefore, pose a minimal </del>risk <del style="color: red; font-weight: bold; text-decoration: none;">to refactoring</del>. <del style="color: red; font-weight: bold; text-decoration: none;">That said, maintaining low fan-</del>in <del style="color: red; font-weight: bold; text-decoration: none;">runs the danger of repeating units of logic in independent modules of your application. A guideline to follow </del>is to <del style="color: red; font-weight: bold; text-decoration: none;">fan-in locally but violate DRY globally</del>.</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>In fact we have many ways of measuring and contorlling the degree and depth of couplings and complexity of our code. <ins style="color: red; font-weight: bold; text-decoration: none;">Metrics that measure </ins>the <ins style="color: red; font-weight: bold; text-decoration: none;">level of coupling include </ins>Law of Demeter, fan<ins style="color: red; font-weight: bold; text-decoration: none;">-</ins>in <ins style="color: red; font-weight: bold; text-decoration: none;">and </ins>fan<ins style="color: red; font-weight: bold; text-decoration: none;">-</ins>out. These metrics describe features in our code that we can look for and count. Moreover, the magnitudes of these counts do correlate with code quality. Consider the fan-out metric<ins style="color: red; font-weight: bold; text-decoration: none;">. It is defined as </ins>the <ins style="color: red; font-weight: bold; text-decoration: none;">number of classes referenced either directly or indirectly from a </ins>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. <ins style="color: red; font-weight: bold; text-decoration: none;">The metric </ins>fan<ins style="color: red; font-weight: bold; text-decoration: none;">-</ins>in <ins style="color: red; font-weight: bold; text-decoration: none;">is a count of all </ins>classes that <ins style="color: red; font-weight: bold; text-decoration: none;">depend upon the </ins>class <ins style="color: red; font-weight: bold; text-decoration: none;">of interest</ins>. <ins style="color: red; font-weight: bold; text-decoration: none;">Knowing fan-out and fan-</ins>in <ins style="color: red; font-weight: bold; text-decoration: none;">we can calculate </ins>an <ins style="color: red; font-weight: bold; text-decoration: none;">instability factor using I = fo / (fi + fo). If I is 0</ins>, <ins style="color: red; font-weight: bold; text-decoration: none;">the package is very stable. If I is 1, the package is very unstable. Packages </ins>that are <ins style="color: red; font-weight: bold; text-decoration: none;">stable are low </ins>risk <ins style="color: red; font-weight: bold; text-decoration: none;">targets for recoding where as unstable packages are filled with dirty code bombs</ins>. <ins style="color: red; font-weight: bold; text-decoration: none;">The goal </ins>in <ins style="color: red; font-weight: bold; text-decoration: none;">refactoring </ins>is to <ins style="color: red; font-weight: bold; text-decoration: none;">move I closer to 0</ins>.</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div><del style="color: red; font-weight: bold; text-decoration: none;">A downside </del>of 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. </div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div><ins style="color: red; font-weight: bold; text-decoration: none;">When using metrics one must remember that they are only rules </ins>of <ins style="color: red; font-weight: bold; text-decoration: none;">thumb. Purely on maths we can see that increasing fi without changing fo will move I closer to 0. However there is 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.</ins></div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div> </div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div><ins style="color: red; font-weight: bold; text-decoration: none;">One downside to </ins>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. </div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
</table>Kcpeppehttp://commons.oreilly.com/wiki/index.php?title=The_Road_to_Performance_Is_Littered_with_Dirty_Code_Bombs&diff=24626&oldid=prevKcpeppe at 11:41, 6 July 20092009-07-06T11:41:35Z<p></p>
<table style="background-color: white; color:black;">
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr>
<td colspan='2' style="background-color: white; color:black;">←Older revision</td>
<td colspan='2' style="background-color: white; color:black;">Revision as of 11:41, 6 July 2009</td>
</tr>
<tr><td colspan="2" class="diff-lineno">Line 3:</td>
<td colspan="2" class="diff-lineno">Line 3:</td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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.</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>In fact we have many ways of measuring the degree and depth of couplings and complexity of our code. Included are the Law of Demeter, Coupling between Objects (CBO), fan in, fan out which create efferent and afferent couplings<del style="color: red; font-weight: bold; text-decoration: none;">, McCabe's cyclometric complexity, </del>and so on. These metrics describe features in our code that we can look for and count. Moreover, the magnitudes of these counts do correlate with code quality. Consider the fan-out metric for example where couplings "fan out" from the 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. Dependencies all "fan in" from classes that reference your class. If for every class in an application these counts are small, you can safely conclude that couplings are shallow and, therefore, pose a minimal risk to refactoring.</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>In fact we have many ways of measuring <ins style="color: red; font-weight: bold; text-decoration: none;">and contorlling </ins>the degree and depth of couplings and complexity of our code. Included are the Law of Demeter, Coupling between Objects (CBO), fan in, fan out which create efferent and afferent couplings and so on. These metrics describe features in our code that we can look for and count. Moreover, the magnitudes of these counts do correlate with code quality. Consider the fan-out metric for example where couplings "fan out" from the 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. Dependencies all "fan in" from classes that reference your class. If for every class in an application these counts are small, you can safely conclude that couplings are shallow and, therefore, pose a minimal risk to refactoring<ins style="color: red; font-weight: bold; text-decoration: none;">. That said, maintaining low fan-in runs the danger of repeating units of logic in independent modules of your application. A guideline to follow is to fan-in locally but violate DRY globally</ins>.</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>A downside of 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. </div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>A downside of 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. </div></td></tr>
</table>Kcpeppehttp://commons.oreilly.com/wiki/index.php?title=The_Road_to_Performance_Is_Littered_with_Dirty_Code_Bombs&diff=24619&oldid=prevKevlin: The road to performance is littered with dirty code bombs moved to The Road to Performance Is Littered with Dirty Code Bombs2009-07-06T09:18:03Z<p><a href="/wiki/index.php/The_road_to_performance_is_littered_with_dirty_code_bombs" title="The road to performance is littered with dirty code bombs">The road to performance is littered with dirty code bombs</a> moved to <a href="/wiki/index.php/The_Road_to_Performance_Is_Littered_with_Dirty_Code_Bombs" title="The Road to Performance Is Littered with Dirty Code Bombs">The Road to Performance Is Littered with Dirty Code Bombs</a></p>
<table style="background-color: white; color:black;">
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr>
<td colspan='2' style="background-color: white; color:black;">←Older revision</td>
<td colspan='2' style="background-color: white; color:black;">Revision as of 09:18, 6 July 2009</td>
</tr>
</table>Kevlinhttp://commons.oreilly.com/wiki/index.php?title=The_Road_to_Performance_Is_Littered_with_Dirty_Code_Bombs&diff=21799&oldid=prevKnit at 16:58, 27 November 20082008-11-27T16:58:14Z<p></p>
<table style="background-color: white; color:black;">
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr>
<td colspan='2' style="background-color: white; color:black;">←Older revision</td>
<td colspan='2' style="background-color: white; color:black;">Revision as of 16:58, 27 November 2008</td>
</tr>
<tr><td colspan="2" class="diff-lineno">Line 1:</td>
<td colspan="2" class="diff-lineno">Line 1:</td></tr>
<tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>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 <del style="color: red; font-weight: bold; text-decoration: none;">makes </del>it very difficult to make a sane prediction.</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>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 <ins style="color: red; font-weight: bold; text-decoration: none;">make </ins>it very difficult to make a sane prediction.</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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.</div></td></tr>
<!-- diff cache key wikicontent:diff:version:1.11a:oldid:21664:newid:21799 -->
</table>Knithttp://commons.oreilly.com/wiki/index.php?title=The_Road_to_Performance_Is_Littered_with_Dirty_Code_Bombs&diff=21664&oldid=prevKcpeppe at 10:09, 22 November 20082008-11-22T10:09:34Z<p></p>
<table style="background-color: white; color:black;">
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr>
<td colspan='2' style="background-color: white; color:black;">←Older revision</td>
<td colspan='2' style="background-color: white; color:black;">Revision as of 10:09, 22 November 2008</td>
</tr>
<tr><td colspan="2" class="diff-lineno">Line 1:</td>
<td colspan="2" class="diff-lineno">Line 1:</td></tr>
<tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div><del style="color: red; font-weight: bold; text-decoration: none;">Improving the </del>performance <del style="color: red; font-weight: bold; text-decoration: none;">of your </del>code <del style="color: red; font-weight: bold; text-decoration: none;">will necessarily involve refactoring it</del>. <del style="color: red; font-weight: bold; text-decoration: none;">Whilst </del>we <del style="color: red; font-weight: bold; text-decoration: none;">may know how </del>to <del style="color: red; font-weight: bold; text-decoration: none;">avoid the messy parts our own </del>code<del style="color: red; font-weight: bold; text-decoration: none;">, the same will not be true for others or for times when we must tune code written by others. In those cases</del>, every overly complex or highly coupled <del style="color: red; font-weight: bold; text-decoration: none;">chunk of code </del>is a dirty code bomb laying in wait to derail the effort. The first casualty of dirty code will be your schedule. If the <del style="color: red; font-weight: bold; text-decoration: none;">road </del>is smooth it<del style="color: red; font-weight: bold; text-decoration: none;">'s </del>easy to predict when you'll <del style="color: red; font-weight: bold; text-decoration: none;">reach your destination</del>. <del style="color: red; font-weight: bold; text-decoration: none;">Lining the road </del>with dirty code makes it very difficult to make a sane prediction.</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div><ins style="color: red; font-weight: bold; text-decoration: none;">More often than not, </ins>performance <ins style="color: red; font-weight: bold; text-decoration: none;">tuning a system requires you to alter </ins>code. <ins style="color: red; font-weight: bold; text-decoration: none;">When </ins>we <ins style="color: red; font-weight: bold; text-decoration: none;">need </ins>to <ins style="color: red; font-weight: bold; text-decoration: none;">alter </ins>code, every <ins style="color: red; font-weight: bold; text-decoration: none;">chunk that is </ins>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 <ins style="color: red; font-weight: bold; text-decoration: none;">way forward </ins>is smooth it <ins style="color: red; font-weight: bold; text-decoration: none;">will be </ins>easy to predict when you'll <ins style="color: red; font-weight: bold; text-decoration: none;">finish</ins>. <ins style="color: red; font-weight: bold; text-decoration: none;">Unexpected encounters </ins>with dirty code <ins style="color: red; font-weight: bold; text-decoration: none;">will </ins>makes it very difficult to make a sane prediction.</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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.</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>In fact we have many ways of measuring the degree and depth of couplings and complexity of our code. Included are the Law of Demeter, Coupling between Objects (CBO), fan in, fan out<del style="color: red; font-weight: bold; text-decoration: none;">, </del>efferent and afferent couplings, McCabe's cyclometric complexity, and so on. These metrics describe features in our code that we can look for and count. Moreover, the magnitudes of these counts do correlate with code quality. Consider the fan-out metric for example<del style="color: red; font-weight: bold; text-decoration: none;">. Fan </del>out <del style="color: red; font-weight: bold; text-decoration: none;">is defined as </del>the <del style="color: red; font-weight: bold; text-decoration: none;">number of classes that are dependent upon a </del>class of interest. <del style="color: red; font-weight: bold; text-decoration: none;">One way to </del>think of <del style="color: red; font-weight: bold; text-decoration: none;">it is </del>a count of all the classes that must be compiled in <del style="color: red; font-weight: bold; text-decoration: none;">order to compile the </del>class <del style="color: red; font-weight: bold; text-decoration: none;">of interest</del>. If for every class in an application <del style="color: red; font-weight: bold; text-decoration: none;">this count is </del>small, you can safely conclude that couplings are shallow and, therefore, <del style="color: red; font-weight: bold; text-decoration: none;">that the couplings </del>pose a minimal risk to refactoring.</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>In fact we have many ways of measuring the degree and depth of couplings and complexity of our code. Included are the Law of Demeter, Coupling between Objects (CBO), fan in, fan out <ins style="color: red; font-weight: bold; text-decoration: none;">which create </ins>efferent and afferent couplings, McCabe's cyclometric complexity, and so on. These metrics describe features in our code that we can look for and count. Moreover, the magnitudes of these counts do correlate with code quality. Consider the fan-out metric for example <ins style="color: red; font-weight: bold; text-decoration: none;">where couplings "fan </ins>out<ins style="color: red; font-weight: bold; text-decoration: none;">" from </ins>the class of interest. <ins style="color: red; font-weight: bold; text-decoration: none;">You can </ins>think of <ins style="color: red; font-weight: bold; text-decoration: none;">this as </ins>a count of all the classes that must be compiled <ins style="color: red; font-weight: bold; text-decoration: none;">before your class can be compiled. Dependencies all "fan </ins>in<ins style="color: red; font-weight: bold; text-decoration: none;">" from classes that reference your </ins>class. If for every class in an application <ins style="color: red; font-weight: bold; text-decoration: none;">these counts are </ins>small, you can safely conclude that couplings are shallow and, therefore, pose a minimal risk to refactoring.</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>A downside of 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. </div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>A downside of 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. </div></td></tr>
</table>Kcpeppehttp://commons.oreilly.com/wiki/index.php?title=The_Road_to_Performance_Is_Littered_with_Dirty_Code_Bombs&diff=21661&oldid=prevKevlin at 09:08, 22 November 20082008-11-22T09:08:07Z<p></p>
<table style="background-color: white; color:black;">
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr>
<td colspan='2' style="background-color: white; color:black;">←Older revision</td>
<td colspan='2' style="background-color: white; color:black;">Revision as of 09:08, 22 November 2008</td>
</tr>
<tr><td colspan="2" class="diff-lineno">Line 3:</td>
<td colspan="2" class="diff-lineno">Line 3:</td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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.</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>In fact we have many ways of measuring the degree and depth of couplings and complexity of our code. Included are the Law of Demeter, Coupling between Objects (CBO), fan in, fan out, efferent and afferent couplings, McCabe's cyclometric complexity, and so on. These metrics describe features in our code that we can look for and count. Moreover, the magnitudes of these counts do correlate with code quality. Consider the fan out metric for example. Fan out is defined as the number of classes that are dependent upon a class of interest. One way to think of it is a count of all the classes that must be compiled in order to compile the class of interest. If for every class in an application this count is small, you can safely conclude that couplings are shallow<del style="color: red; font-weight: bold; text-decoration: none;">. Conclusion: </del>couplings pose a minimal risk to refactoring.</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>In fact we have many ways of measuring the degree and depth of couplings and complexity of our code. Included are the Law of Demeter, Coupling between Objects (CBO), fan in, fan out, efferent and afferent couplings, McCabe's cyclometric complexity, and so on. These metrics describe features in our code that we can look for and count. Moreover, the magnitudes of these counts do correlate with code quality. Consider the fan<ins style="color: red; font-weight: bold; text-decoration: none;">-</ins>out metric for example. Fan out is defined as the number of classes that are dependent upon a class of interest. One way to think of it is a count of all the classes that must be compiled in order to compile the class of interest. If for every class in an application this count is small, you can safely conclude that couplings are shallow <ins style="color: red; font-weight: bold; text-decoration: none;">and, therefore, that the </ins>couplings pose a minimal risk to refactoring.</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>A downside of software metrics is that the huge array of numbers that metrics tools produce can be intimidating to the uninitiated. That said, software metrics <del style="color: red; font-weight: bold; text-decoration: none;">is </del>a powerful tool in our fight for clean code <del style="color: red; font-weight: bold; text-decoration: none;">that </del>can help us eliminate dirty code bombs before they are a serious risk to a performance tuning exercise. </div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>A downside of software metrics is that the huge array of numbers that metrics tools produce can be intimidating to the uninitiated. That said, software metrics <ins style="color: red; font-weight: bold; text-decoration: none;">can be </ins>a powerful tool in our fight for clean code<ins style="color: red; font-weight: bold; text-decoration: none;">. They </ins>can help us <ins style="color: red; font-weight: bold; text-decoration: none;">to identify and </ins>eliminate dirty code bombs before they are a serious risk to a performance tuning exercise. </div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<!-- diff cache key wikicontent:diff:version:1.11a:oldid:12898:newid:21661 -->
</table>Kevlinhttp://commons.oreilly.com/wiki/index.php?title=The_Road_to_Performance_Is_Littered_with_Dirty_Code_Bombs&diff=12898&oldid=prevKcpeppe at 18:55, 1 November 20082008-11-01T18:55:01Z<p></p>
<table style="background-color: white; color:black;">
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr>
<td colspan='2' style="background-color: white; color:black;">←Older revision</td>
<td colspan='2' style="background-color: white; color:black;">Revision as of 18:55, 1 November 2008</td>
</tr>
<tr><td colspan="2" class="diff-lineno">Line 1:</td>
<td colspan="2" class="diff-lineno">Line 1:</td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>Improving the performance of your code will necessarily involve refactoring it. Whilst we may know how to avoid the messy parts our own code, the same will not be true for others or for times when we must tune code written by others. In those cases, every overly complex or highly coupled chunk of code is a dirty code bomb laying in wait to derail the effort. The first casualty of dirty code will be your schedule. If the road is smooth it's easy to predict when you'll reach your destination. Lining the road with dirty code makes it very difficult to make a sane prediction.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>Improving the performance of your code will necessarily involve refactoring it. Whilst we may know how to avoid the messy parts our own code, the same will not be true for others or for times when we must tune code written by others. In those cases, every overly complex or highly coupled chunk of code is a dirty code bomb laying in wait to derail the effort. The first casualty of dirty code will be your schedule. If the road is smooth it's easy to predict when you'll reach your destination. Lining the road with dirty code makes it very difficult to make a sane prediction.</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>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? <del style="color: red; font-weight: bold; text-decoration: none;">Also</del>, the farther away <del style="color: red; font-weight: bold; text-decoration: none;">from </del>the dependency is from the <del style="color: red; font-weight: bold; text-decoration: none;">source </del>the less likely you are to recognize it and account for it in your estimate<del style="color: red; font-weight: bold; text-decoration: none;">. It is these unexpected breakages that put your schedule at risk</del>. All of a sudden your 3-4 hour estimate <del style="color: red; font-weight: bold; text-decoration: none;">may have ballooned </del>to 3-4 weeks<del style="color: red; font-weight: bold; text-decoration: none;">, often </del>this <del style="color: red; font-weight: bold; text-decoration: none;">expansion </del>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 <del style="color: red; font-weight: bold; text-decoration: none;">has ranged </del>from severe to terminal. If only we had a tool to help us identify and measure this risk.</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>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? <ins style="color: red; font-weight: bold; text-decoration: none;">Further more</ins>, the farther away the dependency is from the <ins style="color: red; font-weight: bold; text-decoration: none;">origin, </ins>the less likely you are to recognize it <ins style="color: red; font-weight: bold; text-decoration: none;">as such </ins>and account for it in your estimate. All of a sudden your 3-4 hour estimate <ins style="color: red; font-weight: bold; text-decoration: none;">can easily balloon </ins>to 3-4 weeks<ins style="color: red; font-weight: bold; text-decoration: none;">. Often </ins>this <ins style="color: red; font-weight: bold; text-decoration: none;">unexpected inflation in the schedule </ins>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 <ins style="color: red; font-weight: bold; text-decoration: none;">will range </ins>from severe to terminal. If only we had a tool to help us identify and measure this risk.</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>In fact we have many ways of measuring the degree and depth of couplings and complexity of our code. Included are the Law of Demeter, Coupling between Objects (CBO), fan in, fan out, efferent and afferent couplings, McCabe's cyclometric complexity, and so on. These metrics describe features in our code that we can look for and count. Moreover, the magnitudes of these counts <del style="color: red; font-weight: bold; text-decoration: none;">are correlated </del>with code quality. Consider fan out<del style="color: red; font-weight: bold; text-decoration: none;">, </del>for example. Fan out is defined as the number of classes that are dependent upon a class of interest. <del style="color: red; font-weight: bold; text-decoration: none;">Think </del>of it <del style="color: red; font-weight: bold; text-decoration: none;">as the number </del>of classes that must be compiled in order to compile the class of interest. If for every class in an application this <del style="color: red; font-weight: bold; text-decoration: none;">value </del>is small, you can conclude that couplings are shallow. Conclusion: couplings pose a minimal risk to refactoring.</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>In fact we have many ways of measuring the degree and depth of couplings and complexity of our code. Included are the Law of Demeter, Coupling between Objects (CBO), fan in, fan out, efferent and afferent couplings, McCabe's cyclometric complexity, and so on. These metrics describe features in our code that we can look for and count. Moreover, the magnitudes of these counts <ins style="color: red; font-weight: bold; text-decoration: none;">do correlate </ins>with code quality. Consider <ins style="color: red; font-weight: bold; text-decoration: none;">the </ins>fan out <ins style="color: red; font-weight: bold; text-decoration: none;">metric </ins>for example. Fan out is defined as the number of classes that are dependent upon a class of interest. <ins style="color: red; font-weight: bold; text-decoration: none;">One way to think </ins>of it <ins style="color: red; font-weight: bold; text-decoration: none;">is a count </ins>of <ins style="color: red; font-weight: bold; text-decoration: none;">all the </ins>classes that must be compiled in order to compile the class of interest. If for every class in an application this <ins style="color: red; font-weight: bold; text-decoration: none;">count </ins>is small, you can <ins style="color: red; font-weight: bold; text-decoration: none;">safely </ins>conclude that couplings are shallow. Conclusion: couplings pose a minimal risk to refactoring.</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>A downside of software metrics is that the huge array of numbers that metrics tools <del style="color: red; font-weight: bold; text-decoration: none;">will </del>produce can be intimidating to the uninitiated. That said, software metrics <del style="color: red; font-weight: bold; text-decoration: none;">are </del>a powerful tool in our fight for clean code that can help us eliminate dirty code bombs before they are a serious risk to a performance tuning exercise. </div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>A downside of software metrics is that the huge array of numbers that metrics tools produce can be intimidating to the uninitiated. That said, software metrics <ins style="color: red; font-weight: bold; text-decoration: none;">is </ins>a powerful tool in our fight for clean code that can help us eliminate dirty code bombs before they are a serious risk to a performance tuning exercise. </div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
</table>Kcpeppehttp://commons.oreilly.com/wiki/index.php?title=The_Road_to_Performance_Is_Littered_with_Dirty_Code_Bombs&diff=12897&oldid=prevKcpeppe at 18:45, 1 November 20082008-11-01T18:45:02Z<p></p>
<table style="background-color: white; color:black;">
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr>
<td colspan='2' style="background-color: white; color:black;">←Older revision</td>
<td colspan='2' style="background-color: white; color:black;">Revision as of 18:45, 1 November 2008</td>
</tr>
<tr><td colspan="2" class="diff-lineno">Line 1:</td>
<td colspan="2" class="diff-lineno">Line 1:</td></tr>
<tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>Improving the performance of your code will necessarily involve refactoring it. Whilst we may know how to avoid the messy parts <del style="color: red; font-weight: bold; text-decoration: none;">of </del>code, the same will not be true for others or for times when we must tune code written by others. In those cases, every overly complex or highly coupled chunk of code is a dirty code bomb laying in wait to derail the effort. The first casualty of dirty code will be your schedule. If the road is smooth it's easy to predict when you'll reach your destination. Lining the road with dirty code makes it very difficult to make a sane prediction.</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>Improving the performance of your code will necessarily involve refactoring it. Whilst we may know how to avoid the messy parts <ins style="color: red; font-weight: bold; text-decoration: none;">our own </ins>code, the same will not be true for others or for times when we must tune code written by others. In those cases, every overly complex or highly coupled chunk of code is a dirty code bomb laying in wait to derail the effort. The first casualty of dirty code will be your schedule. If the road is smooth it's easy to predict when you'll reach your destination. Lining the road with dirty code makes it very difficult to make a sane prediction.</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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? Also, the farther away from the dependency is from the source the less likely you are to recognize it and account for it in your estimate. It is these unexpected breakages that put your schedule at risk. All of a sudden your 3-4 hour estimate may have ballooned to 3-4 weeks, often this expansion 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 has ranged from severe to terminal. If only we had a tool to help us identify and measure this risk.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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? Also, the farther away from the dependency is from the source the less likely you are to recognize it and account for it in your estimate. It is these unexpected breakages that put your schedule at risk. All of a sudden your 3-4 hour estimate may have ballooned to 3-4 weeks, often this expansion 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 has ranged from severe to terminal. If only we had a tool to help us identify and measure this risk.</div></td></tr>
</table>Kcpeppe