Attacking Technical Debt

August 26, 2009 by
Filed under: Agility, Process 

Two of the artifacts of incremental or iterative development are that you tend to use scaffolding as you go to prop up the product, and you tend to build similar capabilities in several different locations. Over time these can add up to quite a bit of cruft, or technical debt.

As our system evolves over time, this technical debt has a strong tendency to grow unless we consciously do something about it. Refactoring is the standard approach that is discussed these days. While this effort doesn’t tend to produce a great deal more functionality, it tends to make your job much easier in the future: just imagine the grief of working on a construction site cluttered with all sorts of detritus and a number of slightly different tools available for every task at hand. Confusion reigns.

As a word of warning, I’m going to mention an OS that tends to polarize people into ‘love it’ or ‘loathe it’ groups. Please, let’s forget the brand wars, if just for a moment.

Apple is releasing its latest version of their operating system this week, code named Snow Leopard. While it provides incrementally new functionality, much of what it brings to the table is optimizations and efficiencies from what appears to be a massive refactoring of its code base. The primary statistic that I use for this is their expression of size: they claim that this version of the OS takes up less than half the disk space of the previous version!

Less than half!

A lot of this, I’m sure, comes from more of their evolution of components to their growing foundation layer, but I am sure that some also comes from discovery and refinement of similar functionality that has been resolved into a single function. Regardless of the nature of the changes, to drop the footprint by a factor of two is amazing.

Like many people, I already have my copy on order, and will install it as soon as it arrives, without too much worry. Yes, I’ll have a fresh backup of my information, but my expectation (based on past experience) is that things will go fine, and I will have recovered about 7 Gb of disk space.

With all that refactoring, all that reduction of technical debt, there will be at least some minor glitches. I know that the people that make my Twitter client are scrambling to get a version that works well under the new OS. It is expected that as refactoring takes place, there will be subtle differences that get resolved, and that resolution will go in one direction, which will have an impact on clients that worked based on a set of outdated assumptions.

Be that as it may, though, this appears to be an amazing example of the magnitude of refinement that can be made, and this in a large, widely used application that generally gets rave reviews as it is. It is my understanding that the next version of Windows will be heading in a very similar direction, essentially dealing with much of the backlash that they got when they released Vista. Can’t wait to see the result.

In any application, this technical debt will grow over time, artifacts from the internal development approach, as well as artifacts from the evolution of technology. How are you dealing with it in your application?

Can you imagine cutting the footprint in half, while making the application more functional, faster, and more secure? – JB

If you enjoyed this post, make sure you subscribe to my RSS feed!


2 Responses to “Attacking Technical Debt”

  1. Geoff on August 26th, 2009 9:26 am

    Jim, when this refactoring works it is awesome but changing anything that is currently working is a very nervous proposition indeed. The responsibility being put on the testing activity is immense. All I can think of is that I would have loved to have been in the boardroom at Apple for the discussions on business ROI for all of this activity.

    Refactoring scares the crap out of me.

  2. Jim Brosseau on August 26th, 2009 2:00 pm

    …the responsibility is on testing and planning. When we were building an ATC system iteratively, there were times when we replaced massive chunks of the underlying architecture. Each one of these was a project on its own, with the incorporation into the layers of the architecture planned out and validated at each stage before moving on, until it finally was ‘just a part of the new mainstream’.

    For refactoring to work, there can’t be any ‘I hope things don’t blow up when I push this button’ moments…

Feel free to leave a comment...

  • What’s Happening

  • On The Road Again

    Jim frequently travels across Western Canada for engagements, and welcomes opportunities to meet, run a workshop, Diagnostic or Lunch and Learn session.

    Contact Jim if you would like to connect around any of the upcoming dates:

    • Blissfully at home in Vancouver, BC over the summer!
  • What People are Saying

    If your desire is to effect change or have more influence on a software team, you could either stumble around in the dark for a few years, experimenting with different techniques, or you could buy, read, and apply the techniques in this book. This choice, of course, is up to you.

    — Matt Heusser