Think you know what technical debt is? It might be time to reconsider this assumption in light of evidence put forth by Keith Wood. Like a keen-eyed scientist, Wood was able to confirm that each project team at his company had varying levels of technical debt. What surprised him was that each team, regardless of debt level, performed equally (all other team attributes being constant). But isn’t the level of technical debt supposed to correlate with poor project performance? It appears that this is not necessarily the case.
Wood’s hypothesis (I’m fabricating a title here) states that the impact of technical debt is inversely related to the familiarity of the debt. In other words, if a developer understands the code well enough, this negates the impact of the debt. In the case that the developer is unfamiliar with a code base, or does not recognize certain coding practices as ideal, he or she is more likely to classify those structures as technical debt.
The ‘Newbie’ Variable
One variable that seemed to signal the validity of this idea was the introduction of new team members to the project. When new or inexperienced individuals joined a team, productivity took a hit, leading Wood to believe that these new contributors were struggling to pay the interest on debt that would otherwise be remedied by project veterans.
This information led Wood to a final conclusion – there is no technical way to identify technical debt. It has to be seen as a cognitive phenomenon. Therefore, the “tipping point” as he calls it, is reached only when the value of rewriting the code outweighs the time and effort required. Of course, there are also advantages to fixing technical debt before reaching a tipping point. In the event that a new developer is added to the team, this investment in future productivity is especially valuable since their perception of debt is more easily impacted.
To view the full post, visit: http://trueclarity.wordpress.com/2014/09/04/when-code-is-considered-technical-debt/