Since I started my career in software development, I've read and reviewed code in a variety of languages.  In each of them, I believe I've learned a few things.  I haven't always learned what to do, sometimes it's been an informative overview of what not to do.  Regardless, I thought it'd be worth sharing my notes here:

Classic ASP - I feel a certain appreciation for Classic ASP.  Not only is it the first code I wrote above the byte-level, but it resembles old PHP3/4.  Unfortunately, it hasn't evolved much since that time.  When you find a Classic ASP app, you can count on page after page of HTML validation errors, minimal css and table-based design, and behavior that is inconsistent on anything other than IE6.

If you have more lines of html validation errors than actual code, you might be a Classic ASP developer.

This is the second part of brief summary and description raised by Bruce Tate's book Beyond Java. The first part is available here and seemed to ruffle a few feathers. Since that time, I've finished the book and plan to pass it along to a few other people from whom I'd like to hear some thoughts.

First, let me lay out my Java background. I have about five years of Java experience now. I think I timed it well as I joined the movement about the time Ant and Tomcat were catching the hearts and minds of many Java developers. I have since picked up Maven, Struts, and wading through the fun that is Hibernate and Spring.

In terms of length, I thought the book was very solid. Bruce spent a huge amount of time describing how and why Java became so popular. The summary of which is simple: Java solved many of the pains of the C++ community in a way which was familiar and powerful without being scary. He also posits that the biggest single strength of Java may not be in the language itself, but the JVM. I think I agree with this one. Sun - and the smart people around them - did something fantastic in pushing forward the idea of WORA. Sure, it's not perfect, but it set the standard incredibly high for future competition. I'm not doing justice to Bruce's explanations here, but you get the idea.

I have to say that I've been following the Java vs Ruby war for quite a while. Initially it started as a passing interest due to Nola Stowe's evangelism and heckling. I had a completely wrong idea of what it was and demonstrated that ignorance in this space but once I went to a presentation by Dave Thomas last year, I was convinced:

Ruby - especially because of Rails - is amazing and here to stay.

Therefore, in the past 10 months or so, I've watched technology with great interest. While the hype has been huge, there's been an even bigger warning sign for me. The sheer number of incredibly smart Java people who are picking up Rails. I don't mean that they've said "Hey, this is nifty". I mean people who have essentially dropped Java like a bad habit. There are

I am a log watcher. I regularly "tail -f" numerous files such as catalina.out (Tomcat), log4j.log, and apache's error and access logs. By watching these, I can monitor conditions from test or production users and see what the system is really doing. Sometimes this opens interesting windows into the system and its day to day functioning and sometimes its simply a feel good. Since I have simple notification when something really bad happens, this is mostly to monitor systems for little oddities that pop up through rigorous repeated use. No, unfortunately, I'm not a perfect developer. Occassionally bugs creep in and cause problems... smart people realize this and act accordingly.

Anyway, in the past 6 months, I've been involved in numerous aspects of projects where I've recovered and heavily modified old codebases, tweaked existing systems, or deployed completely new ones. Over the weekend, I was installing some new functionality on CodeSnipers and performed the same process. I plugged into the access and error logs and monitored Drupal's logs to see what was going on.

CodeSnipers has been online since August of 2005 with little downtime, a few upgrades, and numerous additional modules, tweaks, and creative little mods. Luckily, Drupal has exceptional error handling and rarely dumps these back to the UI, so although users have rarely been affected, I decided to delve into a few of the errors. With tweaking just a few files, cleaning up one of the customizations, and refining the spam filters*, we're down to a handful of errors each day. To resolve those last ones, I'd have to get deeper into the code and functionality than time and responsibilities allow.

The point of all of this is that logging can be your friend.... your best friend. Yes, sometimes writing this information to disk or database can slow your application down, but if you want to know exactly how it's being used, there's really no alternative. Make the time to get familiar with a few key tools like grep on the command-line and "group by", sum, and joins in sql. If you know how to parse your logs and watch for the occurance of particular errors - bugs or otherwise! - you can prioritize your efforts to resolve the most critical or annoying issues before considering any of the others. More importantly, you can often determine the exact conditions which caused the error and recreate them yourself at a later time. Better yet, if you have a collection of automated Unit or Integration Tests available, you can use the collected data to replay the process as necessary to fully exercise and evaluate the conditions to make sure it never comes back.

* If you've noticed improvement with the response time of CodeSnipers in the last few months, this is predominantly due to my spam filter tweaking. Previously we were getting upwards of 300 comments/minute at times. The new filter completely blocks an IP address for 24 hours after too much spam is received in a small window. It's still not perfect, but now I'm only seeing about 300/day. Regardless, it's nice to know we're so popular. ;)

Quite a while back, I was heavily involved in a Java project with a stunningly large codebase.  Portions of the code were fantastic and dealt with complicated errors in impressive ways.  The level of design and thought that went into the process was evident by the flow and the handling.  Other portions of the code were just bad.  There are numerous magic numbers, implicit understandings, and fields being misused to represent multiple things.  Although my official involvement with development has ended - they brought development in house, I am still answering various questions and offering clarifications for the new development team, so I still have my hands and mind in the code.  Since I'm already familiar with the codebase, I thought I would improve my refactoring skills and see what happens.

There is no intention or legal ability to release the results of this work.  This is simply an exercise to sharpen and review various skills.

First, I started writing some more Unit Tests.  I believe firmly that you don't have true understanding of the code until you know where it works and where it breaks.  Besides, it's hard to know exactly what to expect from the code if you don't know precisely how it's supposed to work.  Previously I had developed Unit Tests throughout much of the Utils sorts of classes, but now I'm moving up the stack.  I don't know how far up the stack I'll end up climbing, but it's educational regardless.

Next, I've started hammering on it with PMD to get some additional metrics.  I've written all about PMD before and have already used it to analyze this codebase with a specific set of rules.  This time I've expanded the ruleset and added a few to experiment with the results.  While Tom Copeland is often focused on reducing the size of the compiled classes, that's a secondary goal here, so if it happens, great.  If not, no worries.  One more note about PMD...  don't ever turn on all the rulesets at once.  Some of them are directly contradictory and focus on coding style as opposed to function.  You'll end up following the suggestion of a warning in one place only to get a new warning recommending the opposite.

Finally, I've pulled my Refactoring books off the shelf to review.  I fly through nearly anything I read and have a high retention rate but that fades over time.  So every so often, I have to review  this sort of stuff.  Besides, as my experience and knowledge has grown in areas of different business domains, different toolsets, and different developers, I've found that I think and analyze things in new ways.  Therefore every time I review, I discover something new and a new way of looking at things.

What do you do sharpen your skills?  How often do you do it?

Or flavour if you prefer...

I was recently speaking with another developer on a customer site about merging two projects. There is a new project which overlaps quite nicely with what his project does and many of the new requirements are "nice-to-have's" on his project. It seems to make quite a bit of sense, so now all the stakeholders are evaluating this path, but something he said struck me. Paraphrasing, he said "having a second person involved will prevent me from re-architecting it so often. I jump at the flavor of the month." Don't get me wrong, I like the guy, but... Arg.

I think this goes back to Joel Spolsky's Things You Should Never Do, Part I (April, 2000) where he serves up Netscape grilled with a side of fries:
Netscape 6.0 is finally going into its first public beta. There never was a version 5.0. The last major release, version 4.0, was released almost three years ago. Three years is an awfully long time in the Internet world. During this time, Netscape sat by, helplessly, as their market share plummeted.

Well, yes. They did. They did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch.

Almost every developer has been inspired to do this. The first time they start working with Design Patterns. The first time they played with Ajax. Their second project. Whenever they join an existing project and/or have to support an old project.

Before you try to grill me up, let me say that there definitely are times when code, architectures, widgets, operating systems, etc should go back to the drawing board and have some of the fundamental concepts reviewed. No matter how great a system is, without regular review, cruft, junk, and bad ideas slip in and infect the code but this must be done deliberately and with specific reasons. I'm not proud of it, but occassionally I still write temp code "because it works" with the hope of improving it later. Sometimes later actually comes...

Anyway, having a second person involved is going to disrupt how he currently does things. There will be some implicit code reviews, more questions asked, and - more importantly - someone else to coordinate with when architecture changes are desired. I believe this is one of the additional strengths of Pair Programming. Not only do the individuals push the pair along, but they also serve as a brake to slow the decision process and deflect the FOTM Syndrome..