Posted in Operations & IT Articles, Total Reads: 2311
, Published on 18 September 2013
Ward Cunningham, a software engineer from America coined this terminology in 1992. He is one of the pioneers of programming methodology like extreme programming. With his several years of experience and innovative ideas, he has been adding new terms to software dictionary.
What is Technical Debt?
Lets us first recall the meaning of the term Debt. As we know very well, debt word is used in financial domain frequently which means a kind of monetary liability of a party or individual.
Debt is a sort of bond on somebody for accomplishing the agreed contract work.
The same concept gets applied to technology field. Widely used in software development field, technical debt talks about the tasks not accomplished which were supposed to be part of the entire project work.
A system can be in the state of completion with technical debt but definitely contains hidden deficiencies which mars the quality.
In the beginning, the pending activities do not stop the survival or continuation of the project and do not appear fatal to project life cycle. But these works do add values to the project deliverables and the development work.
Moving ahead, the heap of the pending tasks gets large and starts impacting the quality of the work badly.
Lets us have an example to get it understood:
Consider the case of developing a software product handling life cycle of capital market financial product like equity & derivatives.
The well progressing development has some flaws where some sleeping partners are not adding the test cases as part of automated testing. The missing test cases are compensated by the manual testing work.
The tight scheduled project with lack of code review has allowed this to creep in and this pending tasks has started technical debt pool.
Though in the beginning it is not appearing as load, for the subsequent work in the same area will require repeated manual testing. So the debt will be punishing the developer to carry out manual testing every time and make the testing work inefficient.
Also, this will be forever and will make the person its pray who is working on the piece of code.
One can imagine the scene where new functionalities are being added to the existing system and will require manual regression testing because of missing test cases or the technical debt.
Prominent Causes :
1. Individual Poor performance-
Poor performance from a technical person will allow initiating such deficiency in the system. Individual level low quality performance is one of the prominent causes of this debt which gets added upon as the system grows.
2. Inefficient Quality & Control Mechanism -
Lack of good review techniques and implementation of the technical works accomplished are another strong reason of such debt creation. Review should be accompanied with appropriate changes and feedbacks.
3. Carry forward of the debt -
Usually the new person carries forward the technical debt created by the earlier person on the same work.
Many times, in big systems it becomes difficult to get rid of such earlier backlogs and the debt appears as permanent hindrance.
4. Nature of the Biz need -
Tight scheduled biz requirements many times do not provide scope for tracking the technical debts and thus compromise with the quality of the work. This factor is something out of the control of the technical team.
5. Other factors - There could be other factors as well like - poor management support, lack of quality standards, inefficient organization technical culture, lack of leadership etc.
Some of the remedies :
Few steps to overcome this scenario are -
1. Adhere to good technical standards and quality practices.
2. Adopt practices for reducing the technical debt with the ongoing works.
3. Developing the environment for individuals to take proactive steps for avoidance of initiating technical debt.
4. Training and awareness for such aspects
Lets us enjoy our technical work without having future debts!