DevExpress Newsletter 6: Message from the CTO

ctodx
15 July 2009

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.

6 comment(s)
Kevin McFarlane
Kevin McFarlane

I love the metrics feature of CodeRush/Refactor! The fact that it's a dynamic tool is the killer feature. It makes it easy to drive your refactoring efforts there and then rather than having to first run some static external tool.

15 July, 2009
Andy Moyer
Andy Moyer

Very well stated.

-Andy

15 July, 2009
David Guest
David Guest

Since all my  work is for non profit organizations, time is the significant constraint.  I admit to some spaghetti code, some sloppy code, and code that a a professional would laugh at.  However, if it works and solves my client's problems, in the end that is all that really matters.  Furthermore, I picked Delphi as my implementation language, because you can read the code, even the bad code, twenty years later and you can figure out what you were trying to do.

15 July, 2009
Julian Bucknall (DevExpress)
Julian Bucknall (DevExpress)

David: So for fun I looked back at some code I wrote in 1989, twenty years ago. Delphi didn't exist then, but Turbo Pascal in DOS certainly did: version 5.5 was released in May that year. Funnily enough I do have some code from that time (I wrote a library that read/wrote Lotus 1-2-3 files and almost started selling it).

It's readable, but pretty primitive. No objects, no exceptions, global variables, the old-style MsDos() calls, nasty memory management (tests for MaxAvail?), magic numbers, etc, etc. I shudder that there are so many opportunities for the use of an Extract Method refactoring.

On the other hand it did have a complete recursive parser for algebraic formulas and could convert them into Lotus' internal RPN form. (And there was a routine to do the reverse.)

All in all, I'm glad it's the present day and all those things I'm now used to when developing are there :)

Cheers, Julian

15 July, 2009
Steve Sharkey
Steve Sharkey

I've known a few developers who religously follow an 8 or less line of code per subroutine/function body rule.

Whilst I may agree with the thinking behind it, invariably the latest candidate created systems that whilst very clever are pretty much unmaintainable - to make one change you are modifying at least 3 routines, each project seems to consist of 11 or more projects and as for debuging.... just trying to find where the "work gets done" is a huge task that sees you wading through numerous levels of code.

I guess the 8 line of code rule is based upon cognotive theory that says we can keep no more than 5 +/- 2 items in our focus at one time but at least when you go past that if it is all in one or two screens you can jump around simple but when you're scrolling up and down one module and simultaneously flipping between 4 or 5 modules it becomes unworkable.

I totally agree that principles are good (depending on the principles) but to be too rigid with them can lead to problems worse than those the principle was designed to avoid.

16 July, 2009
Greg P
Greg P

I agree that sometimes you just need to stop coding and ship your product. Let's just hope that you don't acrue too much Technical Debt (www.google.com/search) in the process.

16 July, 2009

Please login or register to post comments.