Just like a financial debt, a Technical Debt can be managed easily, or it could become a serious problem for a company. An improper implementation of software code may not be an issue by itself, but if this code becomes a core part of a system, and you start implementing other codes that depend on it, that’s when things start to go out of control. Upgrading / fixing small issues can become a nightmare when there is a huge Technical Debt.
 |
| Time developing (green) versus time solving technical debt effects (red) source: Christiaan Verwijs |
What could be the consequences?
Some of the consequences of having and not paying down the Technical Debt may be:
- Eventually the cost to deliver functionality will become so slow that it is easy for a well-designed competitive product to overtake the badly-designed software/hardware in terms of features (see graph above).
- Badly designed software/hardware can also lead to a more stressed engineering workforce, in turn leading higher staff dissatisfaction (which in turn affects costs and productivity when delivering features).
- Additionally, due to the complexity in a given codebase, the ability to accurately estimate work will also be affected.
- In cases where development agencies charge on a feature-to-feature basis, the profit margin for delivering code will eventually deteriorate.
- and last but not least, poorly design product may fail in critical situations, producing service disruptions that may seriously affect the operations of a customer, the credibility in our products and company and even produce serious financial implications.
Why this happens?
There are many reasons why this happens, to name a few:
- Inadequate or incomplete requirements. Very common situation, were the development starts before a clear definition of the deliverables expected by the customer or the product.
- Lack of communication or understanding of the implication of the rush. Quite often the Technical Debt is originated by Business Management asking for solutions in extremely short timelines, not understanding the implications in terms of Technical Debt. Sometimes this is caused by an improper communication between Technical Management and Business Management, so Technical Management is not able to make Business Management understand the implications of accepting a Technical Debt.
- Not willing to pay. Sometimes everyone understands the need to have some Technical Debt for having things 'ready' as soon as possible, but then there seems not to be 'time' to pay the Technical Debt, becoming an endemic problem. The longer that refactoring is delayed, and the more code is added, the bigger the debt.
- Lack of proper Technical Management. This includes ensuring standards and procedures for development, adequate follow ups and measures of the Technical Debt accumulated, proposals of plans to pay the Technical Debt and prevent as much as possible it's growth. Ensure adequate training of people on usage of modern development tools, enforce documentation and knowledge sharing.
How to handle the Technical Debt
Here are some suggestions to handle the Technical Debt:
- Alignment between business and technical concerns. Incurring Technical Debt allows to release quickly today at the cost of the slower delivery in the future. Therefore, the approach to technical debt should be clearly articulated and negotiated to balance business outcomes over the near and long term.
- Making Technical Debt visible. It is helpful to use tools that make the quality of the software/hardware visible. To build this kind of micro-feedback loop, consider using editors that highlight coding standard violations, or tools that automatically run static code analysis and test code coverage.
- Definition of 'Done'. Although it is an Agile Methodology term, it could be perfectly used by waterfall projects. The definition of done can help avoid and reduce Technical Debt. Elements like required code coverage and code review are examples of injecting the discipline, at a story level, needed to prevent Technical Debt.
- Education and Mentoring. For the Business Management on the implications of Technical Debt and the value of Technical Debt reducing activities; for the Developers, on techniques to prevent Technical Debt.
- Measure Technical Debt. Organizations that are serious about technical debt measure it, something that code/schema analysis tools help with, and more importantly keep an eye on the trends (which should be going down over time). You may choose to track code quality metrics, data quality metrics, usability metrics, time to address defects, time to add features, and many other things.
- Regression test continuously. One of the easiest ways to find problems in your work is to have a comprehensive regression test suite that is run regularly. This test suite will help you detect when defects are injected into your code, enabling you to fix them, or back out the changes, right away.
Conclusion
Although we understand being in a Technical Debt is not ideal, sometimes is the only option to ensure quick results. In such cases make sure to keep track of the Technical Debt, and have proper plants to handle it. Otherwise sooner than later, the situation may become a nightmare that may affect the business success of the company.
Alejandro Alonso
automacomp.blogspot.com
--
Reference
- 11 Strategies for Dealing With Technical Debt. Scott Ambler. http://www.disciplinedagiledelivery.com/technical-debt/
- Using a "Technical Debt Register" in Scrum. Ian Mitchell. https://www.scrum.org/resources/blog/using-technical-debt-register-scrum
- How to Resolve Technical Debt: Pay-off and Prevention with Agility. Don Clos. 2018. https://compuware.com/how-to-resolve-technical-debt-pay-off-and-prevention-with-agility/
- How to deal with Technical Debt in Scrum. Christiaan Verwijs. https://blog.agilistic.nl/how-to-deal-with-technical-debt-in-scrum/
- Project Management and Technical Debt. Agile Alliance. https://www.agilealliance.org/project-management-and-technical-debt/
- Technical debt. Wikipedia. https://en.m.wikipedia.org/wiki/Technical_debt
- Introduction to the Technical Debt Concept. Agile Alliance. https://www.agilealliance.org/introduction-to-the-technical-debt-concept/
- Technical Debt. Technopedia. https://www.techopedia.com/definition/27913/technical-debt
- Technical Debt Explanation and Examples. Maximum Int. http://www.maximumint.com/technical-debt-explanation-examples/
- Static Code Analysis. OWASP. https://www.owasp.org/index.php/Static_Code_Analysis
- Code Coverage. Wikipedia. https://en.wikipedia.org/wiki/Code_coverage
- Regresion Testing. Wikipedia. https://en.wikipedia.org/wiki/Regression_testing
No comments:
Post a Comment