It is essential to locate tech debt in code, and most of the teams do not know the proper way to do it. They find it even more difficult when the code becomes older. The longer back in time the code was designed more is the chance of badness in the code. Therefore, tech debt is not highlighted in the code base, and it is not clear where it starts and where it ends either. Over the time, old and new codes get commingled, and bugs creep from the old defective codes to the newer and probably better-designed codes and starts affecting the functionality of the whole system.
#1: Signs of Warning
It is said that there is not a storm without a lull and similarly there are signs of warning tech debt as well. Therefore, it is necessary to train your team to make them knowledgeable not only about tech debt repayment and refactoring of faulty codes but also to know about the warning signs so that they can determine their canary in the coal mine indicators. If you make your team a well disciplined and organized bunch, they will use different metrics for it. If the velocity of the team drops suddenly, then there must be some refactoring done in the code.
#2: Best Way to Identify
There are several places for tech debts to exist especially in old libraries and integration points, components written in languages which are used less frequently. Codes which are not touched regularly for not causing regular problems are very good place to check and identify tech debt existence. The best way to do such identification job is by the programmers who work with codes on a daily basis. They can discuss it well doing all the heavy lifting and lead to a frank and objective conversation among teams and stakeholders regarding the condition of the code and what needs to be done to improve its functionality.
#3: Analyzing Defect Logs
Detect the smoke to find the fire. When you analyze defect logs and customer support call logs you can get an idea about the code defect as you would come across repeated customer calls regarding a specific section of the code or function, it is very likely that there is a problem in the code and needs immediate reworking. Risks and dependencies of codes are the two attributes that need to be mentioned during refactoring, and you must identify those which are better left as it is than risking and change in it.
#4: Follow Finance Debt Rule
When you identify debts which are to be left alone and find those which need immediate paying off, it is best you follow the rule you apply for judging your multiple credit card debts. You must find out those which you want to pay off immediately with the best consolidation loans and which to leave as it is. You have to consider the upstream as well as downstream results of it and identify tech debt regarding risk and dependency of the defective code.