Hmm.. was the title intriguing enough for you to check out if you as a developer got any debts to clear (such as that represented below :-)? Well, I am talking about what is called as “technical debt” and that is it. 🙂 Believe me, there are high possibilities that most of the developers do have technical debts to clear which they (or someone else) introduce in the system while working on it over a period of time. Lets try and understand what/how/why/whens related with technical debt?
As Fowler writes in his blog, technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Another great article I read on technical debt is titled as the solution to technical debt.
What code/coding approach introduce the technical debts?
Well, code with some of the following code smells add to the existing technical debts:
And, when you quickly want to get started with your application and create something which is demonstrable, you tend to do all of the above, e.g., try and get the functionality done with few classes (long ones), longer methods, and duplicate code. In other words, you introduce the debt to achieve the functionality in quick time. This act introduces what is called as technical debt into the system. However, if these debts are introduced prudently, this gets fixed later in form of dedicated technical debt sprint/releases to avoid several code quality issues in future. The point is that the debt (code smells) yields value sooner, but needs to be paid off (fixed) as soon as possible.
What coding technique do you follow to decrease the debt?
The answer is code re-factoring. In this relation, you may check my blog on re-factoring 3000 lines of code. In brief, you do some of the following to clear off the debts:
In order to understand better, could we categorize these technical debts? Why do they introduced in the system in the very first place?
Lets look at following diagram that I took from fowler’s blog.
Above diagram classify technical debts into following two categories:
Could we avoid technical debt at all?
Simply speaking, we are living in real world and the answer to the question is a big NO. Lets look at some of the scenarios. As the project (or sprint in agile SCRUM) gets kick started, the developers have got primary responsibility to make sure that he delivers the code of decent quality. Now there are two ways to get your coding done:
If you look at both the approaches, you may not be able to avoid technical debt to a great extent whichever way you do. However, some developers (experienced enough) tend to have lesser technical debts associated with them then the other ones (rookies/newbies etc) . That said, this blog says that the developers who are unaware of good design patterns, and coding practices may write not a high quality code but these code may not be called as technical debt.
In recent years, artificial intelligence (AI) has evolved to include more sophisticated and capable agents,…
Adaptive learning helps in tailoring learning experiences to fit the unique needs of each student.…
With the increasing demand for more powerful machine learning (ML) systems that can handle diverse…
Anxiety is a common mental health condition that affects millions of people around the world.…
In machine learning, confounder features or variables can significantly affect the accuracy and validity of…
Last updated: 26 Sept, 2024 Credit card fraud detection is a major concern for credit…