Just came across this post about the 5 code metrics you need to watch.  I thought it was worth mentioning as I just blogged about this below (including something similar a while back).  These are interesting metrics and more high level, but certainly important.  I like labeling duplicated code as something important.  I think we often forget how much we reuse code and have the same mistakes in many places.

Refactoring is a vital component for software developers, helping to prevent their projects from becoming unusable, and unmaintainable spaghetti code. Equally important to some developers, is the notion of refuctoring…check out this tongue in cheek look at Refactoring vs. Refuctoring. Be sure to check out the slide deck at the end.

Refuctoring describes the process of making your code unmaintainable by anybody but yourself.  I love some of the examples of Refuctoring such as “Pig Latin”, “Treasure Hunt” and my personal favorite “Stating the Bleeding Obvious”:

For example:

//initialize a to 1
int a=1;

Not that I’d ever do that (pause while I go clean up some code). Ahem, right anyways I thought I’d throw out some other refuctorings:

1.    “Catch me if you can” – Use so many goto statements that it will make anyone’s head spin.  Especially when you start adding backward goto’s.  Take a look at the CVS source code,  they have some nice (nasty) examples.

2.    “Giant tar pit of hell” – This is hard to blame one single developer as it really encompasses many developers getting together to create one big cohesive piece of crap.  You know you have a problem when you run out of printer toner trying to print these.

"Giant tar pit of hell"

3.    “WTF” – Using names that no one will know…ever.  If you create a bankaccount object, instead of calling it ‘x’, here’s a wild idea, why not call it ‘bankaccount’.  Let’s face it we are all guilty of this.

Now if you really want to be special (I don’t mean in a good way), try combining #1 and #3:

int afunction()
{

there:
   ...
   if(something)
   {
      goto here;
   }
   if(somethingelse)
   {
      goto there;
   }
here:
   ...
   if(somethingelseagain)
   {
   goto end;
   }
end:
...
return;
}

I have to admit, I’m not winning any awards either. It is certainly time to get on the refactoring bandwagon.

Many of us have seen the # of lines of code (LOC) stats that get thrown around as a metric for illustrating how complex software development has become:

• The U.S. Army’s Future Combat System is estimated at 60 million lines of code (MLOC)
• The software that runs the Boeing 787 is almost 7 MLOC, triple that of the 777
• GM says future cars will have >100 MLOC (that sounds high, but hey, <insert GM joke here>)

So, yes there’s a lot of code out there, it’s growing, and it’s getting more complex. It’s tough to put these numbers into perspective… Jack Ganssle has a clever column that does just that:

• A million lines of code printed out would be 18,000 pages
• A million lines of code will typically have 100,000 bugs pre-test
• A million lines of code costs $20m to $40m

I won’t try to compete with Jack on the stats front since that column speaks for itself, and it’s not just the mission/safety critical systems that are trying to deal with the challenges of more code, more complexity, and less time (as in time-to-market). The consumer market is no different. Guess how much code is in the Xbox HD DVD Player? Not the whole system, just the player? 4.7 MLOC. Heck, you could fly an airplane with all that code (hopefully most of it can also be re-used on a non-obsolete disc format). Just as a point of comparison to today’s gaming systems, ask yourself how many software engineers worked on this “game system”:

Yes, I had to throw Digital Derby under the bus didn’t I? Not because I don’t have fond memories of playing this game that was about the size of carry-on luggage. In fact, I played it until the poor little conveyor belt just stopped working and I put up with the, ahem, limitations in the technology. I was actually quite patient (more patient than I am now with technology) and gave my little Digital Derby second and third chances to work properly.

More code, more complexity, impatient customers, and very little margin for error – these are the trends that are driving tool and process automation across the board in the SDLC.