Technical Debt – What it means?According to Ward Cunningham, technical debt is a culmination of all those internal things in your software that you choose not to do but that can become a major problem in future if left undone. These little issues that are often postponed are not visibly prominent issues.
The software program or the application might seem all perfect with high quality but in true sense, the application is all good superficially. These problems are hidden and only a proper scrutiny of the software system will help recognize them. While the Quality Assurance team (QA) might say that the application has quality and a few defects, the technical debt still prevails. If this technical debt is not managed or reduced at the right time, chances are that it will eventually increase the cost of writing/ maintaining the code. This will outweigh its benefit or value to the end consumer.
Technical debt is more or less like a credit card that keeps on adding to the outstanding balance at a very high rate of interest. In case of technical debt however, the costs don’t indicate money but the time and efforts needed to work around the problems. In simpler terms, the more time the team takes to pay off the technical debt i.e. work around to solve the little underlying problems, the more the interest is accumulated in the form of additional workarounds. This will ultimately cause the business to suffer with higher costs.
Truly speaking, the technical debt might not really involve money but it actually can cause financial losses. That’s because the time and effort the developers spend on cracking the code to solve the problem can be spent more productively to add value to the business. The codes are often quite complicated making it again very difficult to find the bugs. This time-consuming process leaves the developers with less time to work on something more valuable hence causing the business and the organization on a whole to suffer financially.
Why does Technical Debt get accumulated?
In the initial phase, writing a code is quicker because the developers write codes without tidying up, without writing unit tests and without doing any Test Driven Development. Hence, the team churns out more number of stories in relatively less time. Writing software requires them to give a decent amount of time for it`s development. A software development process requires working on different levels. It involves addressing the problem as they show up in a case to case basis. However, the underlying problems don’t show up quickly. Doing the right thing, the right way takes more time, especially in the beginning.
Where does the Technical Debt come from?
• Inexperienced developers: Software developer has to constantly upgrade his or her skill set depending on the market trends. This seldom happens. As a matter of fact, many developers write codes for languages like JAVA or C# or Ruby without having the basic knowledge of what a good Object Oriented Code is. As a result, they end up writing codes that are inappropriate or are typically meant for languages they are familiar with like Visual Basic, etc. The onus for this lies on the company too. Many a time’s companies in order to maximize their profits use code developers who are inexperienced i.e. cheap. This practise in turn effects the code and at the end the reputation of the company and hence must be avoided as much as possible.
• Deadline pressure: The pressure of delivering the product within a stipulated time is often a reason for several little underlying problems go unnoticed. Due to their commitment to release the program or application of iteration on a specified date, the developers overlook minor errors and expedite things. These minor errors can in future become major ones causing the application to become unresponsive. Unfortunately, the management also supports the developers without realising that it could end up in high managerial costs.
• Untidy, hard-to-read code: When the code that is initially written is not a tidy one, the next developer who works on it will also not feel compelled to tidy it up or write a clean code himself. This results in a small mess becoming bigger every time a new developer works on it.
• Specialisation: When a code is a specialized one, the developers often back out even if the find that code is a bad one. One, they don’t feel qualified to work on that code and secondly, they don not want to take any extra effort of tidying up a specialized code.
• Over complication: Software developers often tend to over complicate things in order to stay safe from any future problem. They try to visualize the problems that may arise and try to develop codes for such potential problems. In this way, they end up writing codes that go in an entirely different direction without giving them any benefit. Many a times, the code doesn’t really fit the need as it is for a problem that doesn’t even exist. Over design and over complication often takes extra time and effort without any use.
• Over simplification: Contrary to poplar belief over simplification can be also a major cause for a software`s downfall. Software developers sometimes in order to avoid writing excess code language for a program sometimes make the program over simplified which can turn out be just as bad as the point given before this ‘over complication. Sometimes due to this over simplification the software fails to perform when set a little different set of parameters. Software must be flexible enough to be able to cope with at least a decent change of the kind of data. So it highly important that a kind of balance is maintained between the two above points which is actually essential for the success of any software.
• Bad design: Some codes are simply designed poorly. Building on a poorly designed code or working on the code without tidying it up makes the problem even worse.
Finding a solution to the problem
There is no one certain way to solve the problem. As a matter of fact, the solution will take several iterations. It is important to show a level of patience and adopt a multi-pronged approach to reach the solution. Some of the methods have been discussed in brief below.
Planks in the solution:
1. The basic step to solve the problem is to first train the developers in the language that is to be used. Only a proper understanding of the language will help the software developers to write a code that is less prone to have any inherent problems. Also, in order to be successful, it is essential that the trained developers are tested and supported by the pros in that area so that the training results to be effective.
2. The developers and the managers have to be informed about the current problems. Also, the impact of these problems on the business costs has to be ascertained in order to know the significance of the problems. This will clearly indicate the level of problem and the value of solving the problem. The management should also make it clear that it acknowledges the problem and is prepared to start paying off the technical debt that has inevitably arisen.
3. The training sessions on the code smells, Refactoring, Unit Test, Test driven Development have to concisely deal with the inherent problems and aim at reaching a solution. A combination of classroom sessions, web based books and material will enhance the training.
4. The software developers should be given some time (at least 2 hours a week) from their office hours to practice their skills. This practice should be on throw-away codes so that the developers can experiment and come up with new ideas of solving a problem. Time to practice and study is perhaps the best way to diagnose a problem and make the developers confident for solving it in real-time.
5. Using tools such as static analysis, Unit test, continuous integration, and automated acceptance tests helps the teams find, reduce and measure their technical debt load. However, measuring this should not imply that the team will be punished or rewarded for the results. If that happens, even these figures can be manipulated and the end result will only be destructive for the Company.
6. Developers who had undergone and successfully completed their training and also show a visibly higher level of proficiency in their skills should be rewarded. They could be given some token gifts instead of money as such things will give them some recognition and motivate others to develop.
7. Bi-weekly meetings should be conducted over lunch to help the developers meet and discuss the various technical issues that they face. The lunch often helps in getting more attendance and the more the developers, the more technical issues will be solved. Also, people form the senior management should also randomly attend these meets to indicate the support of the management to the software developers.
8. Lastly, a technical debt backlog should be maintained that has records of any technical debt that arises. Whenever a technical issue is reported that can’t be addressed immediately, the developer should be asked to write a Technical Debt card. This will help the Company track the Technical Debt and prioritize its work accordingly.
As is clear from the above, every business has a situation that consists of a problem and an opportunity. The success of the organization hence, lies on how it deals with the problem and how it cashes in on the opportunity.
The Problem: The crux lies in the technicalities of the codes that are developed by the software developers. The code bases of the projects are accumulating technical debt. This has made the entire system to slow down. This basic problem is costing the business financial losses as the valuable time and efforts of the developers is wasted in trying to fix the bugs that arise due to the technical debt.
The Opportunity: With the technical debt becoming prominent, the company has a reason to improve the technical skills of its developers which will in turn help the company to develop new products and deals with the technical issues in-house.
