What is Technical Debt?
I would like to simply define Technical debt as the actions taken by the engineering team to expedite delivery for a piece of functionality that often needs to be refactored at a later point in time. However, there's no one single definition that exists technically.
The term 'Technical debt' was originally coined by software developer, 'Ward Cunningham'. He had coined this term to explain to Non-Technical stakeholders why budgeting needs to be allocated for refactoring.
Cunningham's explanation to the stakeholders was along the following lines:
"With borrowed money, you can do something sooner than you might otherwise, but then until you pay back that money you’ll be paying interest. I thought borrowing money was a good idea, I thought that rushing software out the door to get some experience with it was a good idea, but that of course, you would eventually go back and as you learned things about that software you would repay that loan by refactoring the program to reflect your experience as you acquired it."
Why Technical Debt is necessary?
Typically an early-stage startup needs to validate their product idea first and ensure they can sign up customers rather than build out all the nuts n bolts of the feature. In order to do that, agility is of paramount importance. The engineering team deliberately incurs tech debt to reduce the time to market.
However, often companies have known to abuse this term and prescribe, “Hack it, for now, fix it later” mantra to ship the project fast and acquire more users than their competition. But, often they don't realize that having technical debt has its consequences. Before we dive into that, let us find out the various types of technical debt that exists and how to address them.
Types of Technical Debt
While you can categorize technical debt into more granular level such as code debt, design debt, infrastructure debt, testing debt, etc. I would broadly want to classify them into the following categories:
Planned Technical Debt
As explained above, it is a decision made by the engineering team to take a short-cut for shipping the feature faster.
How to address them?
The tech leads/managers must ensure to track the tech debt in the backlog and address them as the product grows. The Product & Sales team must be made aware of the consequences of not addressing them in a timely manner and everyone should be held accountable to ensure that the tech debt is addressed in a timely manner.
Unintentional Technical Debt
This occurs generally due to the lack of understanding of the product or poor communication that exists in the translation of business goals or simply poor engineering practices.
How to address them?
Retrospectives are necessary no matter how fast a project needs to build. It is imperative to reflect back to find out what went well & what needs to change. Tech leads/managers must involve themselves in understanding the true business objectives and the product team must keep validating the software being built and provide feedback incrementally.
Unavoidable Technical Debt
When there's a huge change in project scope or a complete pivot of technology choice during mid-project, it leads to unavoidable technical debt.
How to address them?
Typically, this is the hardest of them all and usually, the debt is paid back in phases. For e.g. mid-project, the engineering team decides to move from React to Vue. The way to do this would be to create new features for the project in Vue and migrate the existing features from React to Vue in phases.
Is Technical Debt bad?
It's yes and no based on which point in software development you view it. For example, at an early stage, having a technical debt is considered a good thing to ship your product faster to the hands of the end-users. However, as the product matures, it is important to pay back the debt to ensure the product is stable and can actually scale as more and more users start adopting the product.
One important thing to acknowledge is that Technical debt unlike Financial debt is much harder to detect and people generally tend to ignore it unless it really becomes a problem. It is important to have the consequences of technical debt explained to all stakeholders and ensure that the responsibility and accountability are shared between the engineering and product teams.
Conclusion
To summarize, technical debt can be described as the consequences of software development actions that intentionally or unintentionally prioritize client value and/or project constraints such as delivery deadlines, over more technical implementation, and design considerations.
Technical debt should not be confused with the mess. A mess is a just mess that is being created based on laziness and unprofessionalism and has no chance of payback in the future.
I hope you enjoyed the article. Please don't forget to subscribe to my newsletter and connect with me on Twitter @skaytech
You may also enjoy the following articles:
You will also enjoy the following articles:
- Why you should learn 'React'?
- The React Ecosystem
- Async/Await explained in JavaScript
- What are JavaScript Promises
- JavaScript Callbacks Explained
- Everything you need to know about JavaScript Objects
- Everything you need to know about JavaScript Funtions
- ES6 - Higher Order Functions
- ES6 - Spread Operator
- ES6 - Understanding Destructuring
- ES6 - Arrow Functions
- What is Currying in JavaScript?
- Understanding Hoisting
- Introduction to Big O Notation, Time & Space Complexity
Top comments (1)
The article thoroughly addresses what is tech debt, explaining its necessity and management approaches in the context of software development. Particularly valuable is the emphasis on differentiating between planned, unintentional, and unavoidable technical debt, offering strategies for each. Understanding technical debt not only as an integral part of the development process but also as a tool for achieving rapid market entry with subsequent optimization is key to effective project management.