Agile Development

What a hack is Technical Debt

There are technical debts that produce business incentives and there are debts that can be counterproductive, just as in the case of financial debts. Every organization differs in its ability to take on debt safely, track its debt, manage its debt, and pay down its debt. It is highly recommended that before taking on any debt, decision making as well as forwarding should be explicit and clear.

Software is characterized by the sheer expense and labor that goes into finding and fixing its bugs and this is true in its entire history. The repair of bugs starts at the very onset of requirements, it sifts through the process of development and testing and does not stop even when the product is launched, at which the end user sends the feedback and reports his versions of bugs.

Technical Debt as a Software Quality Metric

It was first described by Ward Cunningham in a 1992 paper and today it forms the latest entrant in the software quality metric, the technical debt. Today it has spread virally across the U.S. and the whole world for that matter and forms one of the core topics in testing the quality of software.

The basic idea behind the concept of technical debt is that there would be a greater downward cost if more and more mistakes made during the development and testing phases are let out in the world when the product is launched

Unintentional & Intention Technical Debt

The unintentional technical debt is the first one to come to mind and is simply human error in the form of a novice programmer or common mistakes made during production. This type of debt is a direct result of a job done poorly. There are cases when this type of debt can be unknowingly had, as when a company acquires another company which has acquired significant technical debt but does not reveal that until the acquisition is done. In other bizarre and ironic cases, a team may incur more technical debt simply by making more mistakes during rewrites which was just another attempt to correct a previous debt. 

Intentional debt is the second type of debt. This happens most often when an organization decides to focus more on the present than on the future and thinks that correct decisions taken now to fix debts will minimize possibilities of future debts. Usually it leads to a scenario where the company would write a glue code as a quick fix to synchronize two databases for example, and thinks of rectifying the same when the actual shipment is due. There may even be statements like “We didn’t have time to write all the unit tests for the code we wrote the last 2 months of the project. We’ll right those tests after the release.”

Technical Types of Technical Debt

There are at least five different types of technical debt:

• Design – Poor or quick designs cause this type of debt. Usually such a scenario occurs when we don’t consider the inclusion of system administrators, network, security, DBA’s, etc and quality assurance into the design. In most cases, the above members get neglected in the process.

• Coding – Most people consider this as the purest technical debt and this is caused by coding that is both poor and sloppy, unorthodox usage of methods and practices and using nomenclature that is not conventional.
• Testing – Skipping the creation of automated integration / regression tests and unit tests builds up debt. The company pays for this in every release in the form of manual testing.
• Documentation – Poor documentation of the script so that not everyone is able to understand the whole concept creates this debt. Cost is incurred when the people who totally understand the project become the bottleneck.
• Bugs – The more bugs in your project, the higher will be the debt and the more you have t pay in removing them.

Why Pay Down Technical Debt?

People consider debt to be an affront to the progress and prosperity of the individual and the nation itself. Technical debt is no less. When allowed to grow, it can pose a hindrance in the form of scalability problems, technical issues and a hindrance to development. When you ensure that these debts are minimized, you ensure maintenance costs, greater scalability, increased productivity, and often even higher availability.

In the real world, nobody expects a team to pay off the debt entirely, just as in the case of financial debt, but the focus should be on minimizing the effects of the debt by keeping a constant vigil on the parameters that go into the development of the project.

Reducing Technical Debt:

It is not a good idea to allot a large chunk of manpower to look into the matter of technical debt and resolve issues and this may not be productive in the long term. 

What is usually recommended is that the debt is divided into a number of smaller parts and these parts are included evenly in the workflow of the normal routine of the organization.

Debts should be repaired in every nook and crook of the process. Add tests where there are none. Improve the tests that are poor. Re factor the badly factored tests.

Productivity is impacted less and the idea sells easily.

Conclusion:

Technical debt can be tricky if not managed correctly and sometimes it is a good thing. But the bottom line is that it is fast becoming a buzzword in the Software quality terms.

Technical debt brings to the table doubt, random costs and the premonition of an uncertain future.  You need to apply the same skill and methods used to carry out risk management into managing a technical debt, because both the terms are more or less the same.

There may be a time of crisis if the technical debt is not managed properly and in time.