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!

Comments

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...





  • Search by Topic

  • 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:

    • November 12-13 - Kelowna, BC
    • November 24-25 - Edmonton, AB
    • December 5-8 - Toronto, ON
  • What’s Happening

    Updated!: The popular In Search of Excellent Requirements workshop has been refreshed to reflect Karl Wiegers and Joy Beatty's brand new book, Software Requirements, 3rd edition. Agility concerns and IIBA terminology now included, just as much practicality and utility as ever! Contact us for details!
    September 29, 2014 - New Book!: And now for something completely different - a soft-launch of my new book on LeanPub: Jounce - Crafting a resilient life in an increasingly chaotic world
  • What People are Saying

    One of the key components of UBC PM Intensive program was having Jim as the project facilitator. With Jim’s insight, guidance and support we were able to better understand the framework and approach of project management. I found it helpful that during our group meetings Jim was able to guide and improve our effectiveness by getting us to ask the right questions, to solve our own project problems. He was always there to help improve us as a team and would assist us when we needed to refocus on the task at hand. With Jim’s excellent professional guidance and Project Management expertise he made the PM Intensive program very relevant to our careers going forward. — Don Williams