Archive for December 12th, 2008

• Is Code Foreclosure In Your Future?

  Date: 2008.12.12 | Category: Agile Design, Quality, Refactoring | Response: 0

  I want to use this post to talk about the concept of design debt (or technical debt) to describe the variety of “shortcuts” software developers take to compromise design quality in order to gain a short term boost in productivity.  While there may be many good reasons to take these “shortcuts” at the time, from that point forward any future design changes to that section of the code are more difficult, i.e. expensive to make.  In almost all cases, most well-meaning software developers really do intend to return to the code and fix these shortcomings, but due to schedule pressures they rarely do.  The cumulative effects of these “shortcuts” are called design debt and are very toxic to your software.

  Much like credit card debt, a small amount of design debt is acceptable.  Unfortunately, due to the nature of software, if real attention is not spent “paying back” the design debt, eventually the system in question collapses under the weight of its highly coupled design.  I created the list below to help you spot the four stages of design debt in your system, so to avoid a “repo” of your software.

  1. Impulse Buy - Not doing the right thing today or having the attitude of “I’ll fix that tomorrow”.
  2. Late Payments - Adding new features to new code begins to take longer and longer.
  3. Notice of Default - The project stops adding new features to enter a “refactoring phase” or “just a week for clean-up”.
  4. Foreclosure - It simply becomes easier to re-write the system rather than modify it.

  As you get into later half of Stage Three, more and more of your resources go into paying back debt and you cannot extend the functionality of your system to keep up with market demands.  The competitive advantage your software provided the business falls to the wayside as all your time is spent in maintaining a brittle system your customers don’t even like anymore.  Like most ailments in life, the longer you wait to apply a remediation, the more “painful” the cure.  It is far more economical to apply an ounce of prevention, by taking your vitamins in the form of daily refactoring, than wait for the “foreclosure” process to overcome your business assests.