Technical Debt 101: A Short Quick Guide
Learn the origins, causes and tips to reduce technical debt in your project
👋 Hi, this is Dishit with this week’s newsletter. I write about software engineering, clean code and developer productivity.
Remember, all subscribers can get their code reviewed. So go ahead and click on the Subscribe button.
Have you wondered when people talk about technical debts?
How can so many senior developers still write code that has technical debts?
You are proud of your work. But are you unsure of what constitutes technical debt?
Here is what all you need to know about “Technical Debt”
Origins
The term "technical debt" was coined by Ward Cunningham, an American computer programmer who developed the first wiki and was a co-author of the Manifesto for Agile Software Development
In the early 1990s, Cunningham was working on the WyCash portfolio management system.
The project required rapid development and deployment to meet business demands.
Cunningham needed a way to explain to non-technical stakeholders, the long-term implications of making quick and dirty fixes or taking shortcuts in the codebase.
Cunningham drew an analogy between financial debt and the quick solutions often implemented in software development.
He compared the shortcuts (such as writing suboptimal code to meet a deadline) to borrowing money.
Just as borrowing can accelerate financial growth temporarily but requires repayment with interest, quick coding solutions can speed up development but incur future costs in terms of increased maintenance and refactoring efforts.
The Famous Explanation
Cunningham famously explained the concept as follows:
"Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt."
How Is Technical Debt Created in Projects?
Despite best intentions, there will always be technical debts in software projects. It is like the battery which has its internal resistance. So the output a battery delivers is always minus its internal resistance.
Technical debt can sneak into your projects in several ways:
Rushed Development: When deadlines are tight, you might prioritise shipping features over writing clean, maintainable code.
Example: You copy-paste code instead of refactoring it into a reusable function.
Example: You take an informed decision as there could be a scenario where a dependent system might not be ready and you need to get a tactical fix done.
Lack of Documentation: Skipping documentation can speed things up, but it makes it harder for others (or future you) to understand the code.
Example: You skip writing comments and documentation thinking you’ll “remember it later.”
Poor Testing: Insufficient testing can lead to hidden bugs that need to be fixed later, adding to the debt.
Example: Tests are written towards the end of writing a feature. So some key tests might be missed in the excitement of coding the next feature.
Ignoring Refactoring: As new features are added, failing to refactor the codebase to accommodate them cleanly can create a tangled mess.
Example: You keep adding if-else conditions to handle new cases instead of redesigning the logic properly.
Example: Boiler-plate code is duplicated where a particular functionality is required. Using inheritance or other techniques this can be removed. But until then it adds technical debt.
Avoiding version upgrades: Versions of libraries or the used frameworks need to be kept updated. Each version upgrade also leads to the deprecation of some of the features.
Example: Certain methods and classes get deprecated whenever Java releases new versions. These need to be updated to ensure your codebase is robust as this could have security implications.
Lack of Developer Toolings: There are developer tools like sonar and spotbugs that can detect potential code smells and technical debt.
Integrating them into the deployment pipeline can help you mitigate many of the issues, as these tools can raise flags for common issues.
What If There Is Too Much Technical Debt?
Just like financial debt, too much technical debt can become overwhelming. Here’s what can happen:
Decreased Productivity: Developers spend more time fixing bugs and understanding convoluted code rather than building new features.
Increased Bugs: A messy codebase is more prone to errors, leading to a more unstable product.
Higher Costs: The longer you wait to address technical debt, the more expensive and time-consuming it becomes to fix.
Team Morale: Working with bad code is frustrating and can lead to burnout among developers.
Security Risk: Lack of upgrading to newer versions of libraries and frameworks can lead to security risks that can expose you or your organization to external threats.
Managing Technical Debt
So, how do you manage technical debt? Here are some practical tips:
Prioritize Refactoring: Set aside regular time for refactoring and code cleanup. Treat it as an essential part of your development process. Better still, add code clean-up time as a factor in project estimations.
Example: Allocate a day each sprint for code improvement tasks.
Write Tests: Invest time in writing unit tests and integration tests to catch issues early.
Example: Aim for a certain percentage of code coverage and stick to it. Block builds that does not meet the defined criteria.
Document as You Go: Maintain clear and concise documentation to make future maintenance easier.
Example: Use tools like Javadoc in Java to generate documentation from comments in your code.
Review Code: Conduct code reviews to ensure quality and catch potential issues before they merge into the main codebase.
Example: Implement a peer review system where every piece of code is reviewed by at least one other developer.
Communicate with Stakeholders: Make sure everyone understands the impact of technical debt and the importance of addressing it.
Example: Include technical debt discussions in your project meetings and reports.
In conclusion, technical debt is a natural part of the development process, but it’s crucial to manage it effectively.
By understanding why it happens and taking proactive steps to address it, you can keep your codebase healthy and your projects on track.
Before you go!
If you know someone who is looking to have their code reviewed for technical debts, code smell - look no further.
Help is here.
Just subscribe to this newsletter or reply to this email with word “REVIEW” and I will review your code.