debt.png

Why use this metaphor anyway ?.

I have found that “Technical Debt” strikes chord with Senior management and client. They are able to easily understand this (as they can correlate to Finance) and relate to the consequences.

Just like financial debt, these uncompleted changes incur interest on top of interest, making it cumbersome to build a project. Although the term is used in software development primarily, it can also be applied to other professions.

So how does one incur Technical debt in their projects

Common causes of technical debt may be one or more of below or combination of below.

·         Business pressures, In order to meet the schedule or cost you may not have the time to implement code in an optimum way. Your team would have done a work-around or “hack” in the code. This results in technical debt, this needs to be corrected later when you have time. If not corrected it can result in serious consequences later.

·         Lack of knowledge of IT – Businesses may not understand technical debt and its implications and hence some decisions are made ignoring this aspect.

·         Tightly coupled components, where functions are not modular, the software is not flexible enough to adapt to changes in business needs.

·         Lack of Testing – Due to time , capability or non-availability of tools, software may not have been tested and it leaves some technical debt.

·         Lack of documentation, where code is created without necessary supporting documentation. That work to create the supporting documentation represents a debt that must be paid.

·         Lack of knowledge sharing - junior developers are not properly mentored and hence it results in gaps.

·         Parallel development at the same time on two or more branches can cause the buildup of technical debt because of the work that will eventually be required to merge the changes into a single source base. The more changes that are done in isolation, the more debt that is piled up.

·         Delayed refactoring – As the requirements for a project evolve, it may become clear that parts of the code have become unwieldy and must be refactored in order to support future requirements. The longer that refactoring is delayed, and the more code is written to use the current form, the more debt that piles up that must be paid at the time the refactoring is finally done.

·         Developer capability -  the developer simply doesn't know how to write elegant code.

“Interest” Payments will happen when you will be paying more money for maintaining the piece of software and when you take long time to make changes. Overall your cost of ownership of software goes up.

So is Technical Debt really bad ? Do we need to avoid it or remove it completely ?

Projects are generally executed under many constraints. Practically it may not be possible to completely avoid Technical debt. However after every phase or milestone, you and your team can evaluate what was done to increase the technical debt during that phase and you can allocate some time to clear of the debt.

In case you are not paying of the debt immediately due to timeline pressure, its still good to guage the impact and the extent needed to repair, while its still fresh in the mind of team – members. By identifying debt all along the project and making “minimum payments” as you go will avoid messy situation at later point of time.

I have seen projects where developers will throw up their hands as its too convoluted to make corrections to the messy code they or someone else has written.  When asking for more time, You can explain to your client or management using this jargon and in all probabilities your time will be approved. 

References

• http://www.construx.com/10x_Software_Development/Technical_Debt/ 
• http://martinfowler.com/bliki/TechnicalDebt.html
• http://www.sonarqube.org/evaluate-your-technical-debt-with-sonar/ -- Tool to evaluate technical debt.
• http://theagileexecutive.com/category/technical-debt/page/2/

Parts of article taken from Wikipedia.org