Blog

Earlier this month I blogged about some of the reasons people have given for not upgrading core language libraries.  One of the most common I heard, and one that bugged me the most, was “There has not been enough time/resources dedicated to migrating because we’re focused on building application functionality...” I threw the excuse flag out at that one, and today I am going to take a little more time to explain why…

As I said last time, This is not just a poor excuse, it is also a fallacy.  Migrating the application is building functionality. It might not be as visible as some of the other functional pieces, but it is just as important over the life span of the code.  And the sooner you upgrade the application, the smaller the effort.  This is because a normal application grows and evolves over time.  When Java 1.5 was first released, the enterprise application I am currently supporting contained around 50k non commented lines of code.  In the five years (and another major Java version since), that same application has increased several times over in size.  Currently it has over 100k non commented lines of code in one of the supporting libraries alone.  Add up the LOC in the 14 dependent modules and we are looking at nearly 500k lines of code.  Which one would you rather upgrade, the 50k LOC from 2004, or the 500k LOC application of today?  Thankfully, we had upgraded to 1.5 in a timely manner, and we are prepared to move to Java 1.6 when the application server it resides on makes the jump.

In order to keep the amount of effort needed to make the change to a minimum, it is also important to migrate in increments.  The jump from Java 1.3 to Java 1.4 is (obviously) significantly smaller than the jump from Java 1.3 to Java 1.6.  Use driving a vehicle as an analogy.  If you are used to driving a compact hybrid car, moving up to a full size sedan would be a change, but not one that would overly tax your ability to do so.  After you have gotten used to the sedan, moving up to a full size pickup would once again force you to change your driving habits, but you could likely handle it.  Now imagine if you had gone directly from the compact hybrid to the full size pickup.  See the difference?  The level of effort needed to make major jumps is greater than the sum of the effort to make the two smaller jumps.

In the end, continuing to build functionality in your application by upgrading core libraries in timely and incremental changes makes the upgrade more manageable.  As core libraries change (as they always will), working upgrades into the normal life cycle development of the application will not only save time and resources in the long run, but will also increase the overall longevity of the application itself.