The metric system for code
If you've been developing for any length of time, you'll have come across any number of studies that correlate "bad things" against some form of software metric. The first book to really summarize these studies (although it's now getting a little long in the tooth) is "Code Complete" by Steve McConnell, but there have been others since that address code quality.
So we have the correlation between lines of code in a method and the "maintainability" of the code, or the Cyclomatic Complexity of a method and its testability, or the coverage percentage for a method and it's likelihood to contain bugs, or the coupling/cohesion of a set of modules and its flexibility when the demands for enhancement arrive.
In other words, for some metric, there's some benefit to reducing (or increasing) its value. For some set of metrics, the problem becomes a little harder since you're increasing the number of measurement dimensions you can alter and therefore the number of resulting behaviors of the code. It starts to look like a linear programming problem.
However, there is one metric to rule them all: time. At some point, you have to ship a product or an application. You do not have the luxury of infinite time to tweak your other metrics to solve the quality code problem. You have to ship the best software you can in the time allotted, and if that means ignoring your favorite code metric then so be it.
Julian M Bucknall, CTO
Comment on Julian's message |
