{"id":71,"date":"2019-12-20T18:41:03","date_gmt":"2019-12-20T18:41:03","guid":{"rendered":"http:\/\/ctoinsight.com\/?p=71"},"modified":"2020-01-03T23:55:24","modified_gmt":"2020-01-03T23:55:24","slug":"software-complexity","status":"publish","type":"post","link":"https:\/\/ctoinsight.com\/index.php\/2019\/12\/20\/software-complexity\/","title":{"rendered":"Software complexity – Is it worth measuring?"},"content":{"rendered":"\n

Software is among mankind\u2019s most complex creations. How do we measure software complexity and does it even make sense to do so?  When I think of the most complex structures we have created, the arts (especially music), and \u2026 software come to mind. From an economic perspective, we consider software complexity to be a bad thing because the more complex the software, the more time and expense it takes to build and maintain.  But sometimes it needs to be complex in order to solve complex problems.  There can also be an aesthetic beauty to software that only developers seem equipped to appreciate. I recall once looking at code that controlled a spacecraft and being blown away not only by its complexity but also how by how very well written it was.  <\/p>\n\n\n\n

Music is different in that how complicated it is seems to affect people in different ways.  The high level of complexity in a Mozart<\/a> symphony seems to contribute to its immortality. On the other hand, simple popular music tunes have a wide fanbase.<\/p>\n\n\n\n

Complexity of Music<\/h2>\n\n\n\n
\"Fractal\"<\/figure><\/div>\n\n\n\n

In his 1933 book Aesthetic Measure<\/a><\/em>1<\/sup>, preeminent American mathematician George David Birkhoff<\/a> proposed a mathematical theory of aesthetics. In the course of writing the book, he spent a year studying art, music, and poetry of various cultures around the world.  He developed a formula to measure the aesthetic quality of an art object (e.g., a work of music) as being the ratio between its order and complexity.  Since that time, researchers have built upon his work to come up with other ways of analyzing complexity of music. Mandelbrot\u2019s<\/a> prot\u00e9g\u00e9 Richard Voss together with John Clark<\/a> applied fractals<\/a> to mathematical analysis of music2<\/sup>.  April Pease <\/a>and her colleagues extended this work by searching for the presence of crucial musical events based on an analysis of volume and using this as a measure of complexity3<\/sup>.  I find it interesting that in music complexity, the performance is measured, not the static sheet music (or electronic equivalent).  Music played by a computer reading sheet music has been found be less complex than a performance by accomplished musicians!<\/p>\n\n\n\n

Software Complexity<\/h2>\n\n\n\n

The software profession has struggled with how to measure software complexity for decades.  Thomas McCabe came up with the idea of using Cyclomatic Complexity<\/a> to measure the number of logical paths through code4<\/sup>.  But this has been shown to not be any better than just counting source lines of code (SLOC).  Two methods currently in use are a set of six metrics proposed by Shyam R. Chidamber and C.F. Kemerer<\/a> specifically designed for object-oriented code5<\/sup>, and a different set of six metrics proposed by Maurice H. Halstead<\/a>6<\/sup>.<\/p>\n\n\n\n

Comparison of Software Complexity Metrics<\/h3>\n\n\n\n
\n Chidamber and Kemerer Metrics<\/strong>
Note that these metrics are per class so you would sum them up for\n all classes in the program<\/small>\n <\/td>		\n Halstead Metrics<\/strong>\n <\/td><\/tr>
WMC<\/strong> – weighted methods per class is the sum the complexities of each class method but they used a complexity of 1 for each method so this is really just the number of methods in a class <\/td> Program Vocabulary<\/strong> n = n1<\/sub> + n2<\/sub>
\n n1<\/sub> \u2013 number of distinct operators
\n n2<\/sub> \u2013 number of distinct operands <\/td><\/tr>
CBO<\/strong> – coupling between object classes is the number of other classes which are coupled (using or being used) <\/td> Program Length <\/strong>N = N1<\/sub> + N2<\/sub>
\n N1<\/sub> \u2013 total number of operators
\n N2<\/sub> \u2013 total number of operands\n <\/td><\/tr>
RFC<\/strong> – response for a class is the number of methods called by each class method summed together <\/td> Calculated Estimated Program Length<\/strong> = n1<\/sub> log2<\/sub> n1<\/sub> + n2<\/sub> log2<\/sub> n2<\/sub> <\/td><\/tr>
NOC<\/strong> – number of children is the sum of all classes that inherit this class or a descended of it <\/td> Volume V <\/strong>= N x log2<\/sub> n <\/td><\/tr>
DIT<\/strong> – depth of inheritance tree is the maximum depth of the inheritance tree for this class <\/td> Difficulty D<\/strong> = (n1<\/sub> \/ 2) x (N2<\/sub> \/ n2<\/sub>) <\/td><\/tr>
LCOM<\/strong>– lack of cohesion of methods measures the intersection of the attributes used in common by the class methods <\/td> Effort E<\/strong> = D x V <\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Measuring Software Complexity<\/h2>\n\n\n\n
\"Measurement\"<\/figure><\/div>\n\n\n\n

So why should we care about measuring software complexity?  Here are some claims, in many instances being made by companies that are selling complexity measurement products or consultants that will help you figure out how to use them.<\/p>\n\n\n\n

Better estimates on software maintenance effort<\/strong><\/h3>\n\n\n\n

I suppose if you had enough empirical data to somehow relate\ncomplexity to maintenance cost, this might be useful.  There certainly have been a lot of studies on\nthis.  The problem is that there are other\nsignificant factors that affect software maintenance costs like <\/p>\n\n\n\n