Derik Whittaker

Syndication

News


Do you have an Action Plan to Tackle your Technical Debt?

As a general rule all software development teams will create technical debt during the construction of their product.  Creating this debt is in no way an indicator that the team is bad or not talented, but rather is an indicator that they understand that there are always tradeoffs when building an application.  The fact of the matter is we are in the business of building applications which need to get to market and while building these applications we will be faced with decisions about trade off's. 
Now I stated that creating technical debt is not any indicator of talent, but I will say that not creating an action plan to resolve this technical debt is a major indicator of experience.  All software teams must maintain a list of items (non-business features) that need to be addressed at some point in the future.  They need to mandate that this list be reviewed on a regular basis and priority be put on each item along with an action plan.

What counts as technical debt? .... Anything :)  No really:

  1. Design trade offs you make
  2. Areas in code which could be simplified by the addition of a new tool or library (this may not have been a technical trade off at the time of construction, but new libraries could simplify the code.
  3. Areas in code 'that are not to be touched for fear of breaking' (you KNOW your projects has these dark corners)


Why Technical Debt is created?

  1. When faced with a decision in regards to 'simple, quick, easy but not the best' or 'longer, more complicated but right' many times we reach for the 'easy button'.  Reaching for this easy button is ok, but only as long as you understand the tradeoffs.
  • Deadlines loom and we 'cut to finish'.
  • Poor decisions were made by the team
  • The team lacks the experience to make good decisions (not normally the case, but it can be)
  • Why Technical Debt is a burden on your project?

    1. It creates roadblocks for new development
    2. Can increase complexity in your codebase making new features more difficult to create
    3. Causes re-work to be performed in the future, which could take longer than had it been done 'right' in the first place


    Why having the list is a good thing?

    1. Keeps the list visible and if it is visible it will receive attention
    2. Keeps people informed of bad (potentially bad) tradeoffs which were made in the past
    3. Keeps people informed of potential refactor points


    Why having the list is a bad thing?

    1. Admits to others (especially management) that your code may have flows (I actually see this as a good thing, but others do not)
  • Reminds you of all the bad decisions you made... wait that is bad... NO

  • How we maintain our action plan for Technical Debt?:
    Our team has created a list in our team wiki and grouped the items in the list by product feature.  Each team is expected to add items to this list as they come across items in code which need to be addressed in the future.

    When we add our items we provide the following level of information:
    Short Description:
    Original Reason for the debt (if known):
    Risk of change: (high, meduim, low)
    Risk if not changed:
    Action Plan:
    Date/Release Debt removed:


    At the end of the day the code you build is the code you are going to be required to maintain over the long haul.  If you make the decision to not activily address your technical debt not only will your pain increase while working on your codebase but your customers will start to suffer because the cycle time to create new releases will increase and new features will flow slower and slower.

    Till next time,


    Posted 04-09-2010 6:20 AM by Derik Whittaker

    [Advertisement]

    Comments

    Jeff wrote re: Do you have an Action Plan to Tackle your Technical Debt?
    on 04-09-2010 11:50 AM

    Our team adds technical debt items as defects to the product backlog, since that's essentially what they are. We then track them as regular work items during upcoming sprints, fitting them in as time permits. What I like about your approach is setting a specific goal for clearing said debt out, and I will be looking to incorporate this on our  team shortly.  

    Paul Eie wrote re: Do you have an Action Plan to Tackle your Technical Debt?
    on 04-09-2010 3:57 PM

    Great article Derik!

    nappisite wrote re: Do you have an Action Plan to Tackle your Technical Debt?
    on 04-12-2010 9:57 AM

    Our team maintains a list of technical projects. Its not explicitly a technical debt list, but maybe it should be.  The concept has been gaining some traction on the business side lately. I've even had requests to quantify the remaining debt.  

    I like the format of your log information. I may try and incorporate something like that.

    Kit wrote re: Do you have an Action Plan to Tackle your Technical Debt?
    on 04-12-2010 10:32 PM

    I like the concept of what I call a "Buffer Release". A short buffer release adds no new business functionality but is a formal part of an agile lifecycle in which technical debt is the primary (preferably only) focus. This is a hard-sell, but showing how it can shorten the next few business releases will make such a thing more palatable. This focuses development and helps to set expectations for project management and business.

    Our team also marks technical debt in code (e.g with a Resharper pattern) and links it to the defect/bug/task tracker of your choice.

    Chris Melinn wrote re: Do you have an Action Plan to Tackle your Technical Debt?
    on 04-13-2010 10:02 PM

    Thanks Derik, nice post on the technical debt.

    I wrote an article on technical debt from a slightly different perspective here:  chrismelinn.wordpress.com/.../sacrificing-quality-costs-more-than-you-think

    Your post helped me realize a couple things again.  By creating (and publicizing) the list you suggest, it highlights the fact that developers consciously made those decisions.  Yet another reason "Why having the list is a good thing?"  

    It can help reduce the developer's subconscious feeling about the level of quality, and allow them to put those feelings aside a little more.  They will hopefully know that the trade-offs are not forgotten and will be addressed in the future.   It helps other realize that they are writing "bad code", but that they intentionally made those decisions with the intention of coming back later.

    Thanks again for the nice article.

    About The CodeBetter.Com Blog Network
    CodeBetter.Com FAQ

    Our Mission

    Advertisers should contact Brendan

    Subscribe
    Google Reader or Homepage

    del.icio.us CodeBetter.com Latest Items
    Add to My Yahoo!
    Subscribe with Bloglines
    Subscribe in NewsGator Online
    Subscribe with myFeedster
    Add to My AOL
    Furl CodeBetter.com Latest Items
    Subscribe in Rojo

    Member Projects
    DimeCasts.Net - Derik Whittaker

    Friends of Devlicio.us
    Red-Gate Tools For SQL and .NET

    NDepend

    SlickEdit
     
    SmartInspect .NET Logging
    NGEDIT: ViEmu and Codekana
    LiteAccounting.Com
    DevExpress
    Fixx
    NHibernate Profiler
    Unfuddle
    Balsamiq Mockups
    Scrumy
    JetBrains - ReSharper
    Umbraco
    NServiceBus
    RavenDb
    Web Sequence Diagrams
    Ducksboard<-- NEW Friend!

     



    Site Copyright © 2007 CodeBetter.Com
    Content Copyright Individual Bloggers

     

    Community Server (Commercial Edition)