What Technical Debt Is
In the software development process, there is a term called Technical Debt. This is a common metaphor that is used to refer to the short-term decisions you make while writing code, this usually happens when you have strict timelines and managers/stakeholders pushing you to get something into production.
This is Wikipedia definition:
“Technical debt (also known as design debt or code debt, but can be also related to other technical endeavors) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer”.
Technical debt is similar to any other debt e.g. you take a loan to buy a house. You have the house now but it will take years to pay off your loan. The same is the case with technical debt, it can give you leverage to deliver a product on time but on the cost of quick and dirty development. It’s a trade-off between quality and time, and if you don’t deal with this debt then it can hurt you in the long term.
How Technical Debt Happens?
There are quite a few reasons that can cause technical debt. Let’s look at some of the most common.
Business Goal Collision with Software Implementation
One of the most common reasons for technical debt is the clash of organizations’ business goals and the plan with software design and implementation. It is almost impossible for any organization to make sure that every business goal is known upfront, So, the developers are forced to deliver a product with changing requirements on time.
Bad Coding Practices
Sometimes technical debt is caused by the bad poorly written code by the developers. This frequently happens when you change teams and don’t have someone overseeing the architecture. Everyone sees problems different
Over-Complex Technical Design
One of the causes of technical debt is the over-complexity of technical design. This makes the implementation of the product too complex which forces developers to use shortcuts to achieve the deadlines. Always remember to KISS (Keep it simple stupid) whenever you can.
Types of Technical Debt
For years people have defined different types and forms of technical debt. The one I like to go with is provided by Martin Fowler in the “Technical Debt Quadrant”. In this quadrant, Martin categorized the technical debt into four categories. According to Martin, debt can be based on intent i.e. deliberate or inadvertent. And then Martin classified them further into two types whether they are Reckless or Prudent.
See the figure below provided by Martin what he called a technical debt quadrant.
What To Do If You Have Technical Debt
Access The Technical Debt
The first thing you need to do is to have a clear assessment of how bad the debt is. Measure the approximate time the developers would need to refactor and clean the code and compare it with the other milestones of the project. This will help you identify how many resources you would need to pay off the debt. Remember you can pay it down, just like a house or car not over time.
Address This As Early As Possible
Once you are in technical debt, you have to address the issue whether it is now or a year later. Take my advice and deal with it as early as possible. Don’t rely on the “We will deal with this later” approach because in practice it will never get here :-0
The best Practice
The best practice is to avoid technical debt in the first place and develop a company culture to discourage the shortcuts or quick fixes in the code. You can use different strategies such as pair-programming or test-driven development to avoid building technical debt.
Make sure you have a gatekeeper on the code
If you don’t have someone managing the overall technical aspects of the project it’s bound to get messy. Appoint someone to monitor pull requests and conduct code reviews with developers. It will not only help the project but the growth of your developers also.
