DevExpress Newsletter 6: Message from the CTO

My Message from the CTO in our sixth newsletter:

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 its 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.

I suppose what I'm arguing here is by all means write your code in the first place to follow some of your favorite metrics (one of mine is Cyclomatic Complexity max 10 or less, usually 5 or less, and it's easy to check with CodeRush), but don't get all hot under the collar that some code misses the mark. Time is usually of the essence, so be flexible about the rest, so long as you're not abandoning all your principles.

Free DevExpress Products - Get Your Copy Today