10 votes

You should work at identifying technical debt, paying it down, and making sure it doesn’t keep popping up as fast as you can knock it down.

2 comments

  1. [2]
    Kenny
    Link
    A bit late to the discussion, I found the last two bullet points intriguing. One of the issues that I see in my new job is the amount of technical debt that has accrued. I believe that it will be...

    A bit late to the discussion, I found the last two bullet points intriguing.

    • Don’t take the easy way out. Keeping technical debt at bay requires a systematic approach.
    • Fostering a culture that prioritizes management of technical debt—sometimes even offering incentives—is the best way to go.

    One of the issues that I see in my new job is the amount of technical debt that has accrued. I believe that it will be an important initiative for me to start paying off some of the debt soon. Any ideas on buy-in approaches for administration who may not be technically inclined? Finally, any thoughts as to what incentives have been used as examples to work off of for my organization?

    1 vote
    1. Emerald_Knight
      Link Parent
      Your biggest hurdle is likely to be management, and your best bet with them is to find a way to generate a quantitative measure of the impacts of technical debt on your project(s). Give them solid...

      Your biggest hurdle is likely to be management, and your best bet with them is to find a way to generate a quantitative measure of the impacts of technical debt on your project(s). Give them solid figures and projections on how those numbers will get worse. Show them how it affects their bottom line. Show them the benefits of paying down the debt in terms of initial upfront costs vs. cost savings so they can see when managing the technical debt starts paying off.

      Do you have examples of a feature that would ordinarily take very little time to implement but ended up taking weeks of work just to work around the technical debt? Bring those up. Tell them how much it should be costing them to develop these features vs. how much it is costing them. Was there a really simple bug that needed to be fixed that took several days to track down because the code was a complete mess to follow? Bring that up, too. Especially bring up any problems that are repeat offenses because those will be the strongest indicators of the debt that has accrued.

      If there's one thing that a non-technical person will understand, it's their bottom line.

      As for incentives, I've got nothing for you. My own incentive is to not deal with a massive headache every time I want to make a change to code. The thing about the phrase "work smarter, not harder" that people tend to miss is that you have to do the "work harder" bit upfront for a while so that you don't have to do it all the time.