If you have been working in the software industry for any period, there is a high chance you’ve heard of the term ‘Technical Debt’. A programming theory which chooses prioritisation and speedy delivery over perfect code, this is also referred to as ‘Design Debt’ or ‘Code Debt’, often used as a tool for “getting ahead”. The mediocre code used instead, is usually redundant, poorly designed, useless, or all three, this code is called cruft. While this type of debt is something that development teams usually want to avoid, it’s not always easy depending on the project’s priorities and time frame. However, is ‘Technical Debt’ bad or good? Can using cruft code really be beneficial for a project in the long run. The simple answer is that it is neither good nor bad, its debt.
‘Technical Debt’ can be created intentionally, teams use this compromise between time and speed to produce a minimum viable product. If the prototype is worthwhile, they will have an opportunity to develop and improve based on end-user feedback. So, sacrificing a little bit of quality to release new functions and features on time could help with the production of your digital product, especially with the increasing pressure of the market and competitive forces. However, post-release of the product is a critical time and it’s important that teams schedule a time to measure their ‘Tech Debt’ and create a plan to remove the cruft code. Just because its seen as a time-saving solution doesn’t make it smart to use for every project, if the code is poorly written or architected and can’t be refactored, that’s not just bad software development, that’s a bad product.
The downside of ‘Technical Debt’ is that time needs to be scheduled later on to fix the development work when mediocre code is implemented in the short run. Whether it’s worth taking the time in the first place to write good code or scheduling time later to replace the cruft depends on the project you are currently handling. Just like a bank loan, debt is still debt and ‘Tech Debt’ is also capable of charging “interest” that you’ll need to pay back. Forgetting to pay off this debt will let it continue to accumulate having a roll-on negative effect on budgets, software developers and resources, not to mention demoralising for developers that have to take days to finish simple tasks because of mediocre code. While initial development teams are able to move faster when creating ‘Tech Debt’, its only for a short period of time before its necessary for them to go back and refactor cruft code or risk the overall integrity of the digital product. Minimising ‘Tech Debt’ reduces the risk, improves agility and delivers the best results.
Debt can get scary whether it’s financial or other, but there are some simple ways to ensure you maintain a low risk ‘Tech Debt ‘during development of new projects. Discuss it early on in the conversation, you will be able to account for the impact of short-term decisions on long-term projects and create a plan for paying off ‘Tech Debt’ at the beginning. Making time at the end of each sprint or each month to engage in code reviews that reduce ‘Tech Debt’. Another way to manage ‘Tech Debt’ is with extensive documentation, which is already a good software development practice when done correctly and when tweaking the process can become incredibly useful for refactoring cruft code.
So, determining whether ‘Technical Debt’ is good or bad depends on the context of the project but the same key principal that applies for all types of debt is that it’s not problematic until it is, management is key.
Comments