DevOps Zone is brought to you in partnership with:

Software Developer, Mentor, Architect and UX/UI craftsman. Also, a psychology nut that loves curling. Zac is a DZone MVB and is not an employee of DZone and has posted 66 posts at DZone. You can read more from them at their website. View Full User Profile

Technical Debt: Making the Case

09.20.2012
| 6908 views |
  • submit to reddit
Technical Debt in programming is a topic for the ages. It tends to permeate round table conversations and almost pre-dates physical development. Although its accumulation has no discernible pattern, time and money are common factors. A company's lack of concern for technical debt can be frustrating to some developers. They tend to blame and point the finger at sales, management, ownership, or other groups. In many cases, they should start by blaming themselves. How did they convey the importance of the debt? Its impacts? Its downstream costs? Its upfront costs? Developers must don their sales hats and make the proper case. Assuming most programmers are not closet salesmen, the following sections may help.

Things to Remember

  • Behind each technical debt is a developer. Be sensitive towards the problem and don't blame the coder. This is a team problem.
  • Many non-technical people do not understand the phrase "technical debt." Spend the time to educate them.
  • Be prepared for angry/frustrated individuals. Sometimes technical debt is perceived as a failure to execute properly.
  • Recognize there are two types of technical debt: existing and future. Identify how to tackle each.
  • Do not tackle larger debt items without approval. This encourages distrust.
  • Understand that a company has priorities. Development is part of a larger puzzle. Don't expect all debt to be tackled at once.

Preparing

  • Have each area of technical debt outlined, categorized, and sorted.
  • Try to provide multiple solutions to a problem. Don't forget to include any risks and an estimate of time. Presenting options encourages trust within the decision making process.
  • Where applicable, provide statistics on each problem area. Time spent, projected future allocation, etc.
  • If statistics are provided, be prepared to defend them.

Making the Case

  • Check all attitudes at the door. Even though the debt might be known to a group or department, the larger group is probably unaware.
  • Be patient when explaining concerns. A common understanding must be reached before moving forward.
  • Understand that buy-in is very important. They are the customer. Don't lose them.
  • Refrain from large proclamations such as "We need to tackle [blank] now." This tends to invoke defensiveness.
  • Do not provide ultimatums. Avoid statements such as "If we don't do this, it will fail." This tends to invoke anger.
  • Use visual aids. Spreadsheets and white boards help people get on the same page. They can adapt to the conversation quickly.
  • If possible, recommend a small recurring time window to tackle debt.

Final Thoughts
Technical debt has been compared to credit card debt. This is a great adage. Credit card debt is usually accumulated over a period of time. Although it can be consolidated, paying it down takes time. If ignored, it will catch up with the debtor. Technical debt follows these same guidelines. It should not be ignored but is impractical to tackle all at once.
Published at DZone with permission of Zac Gery, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)