Technical Debt: Measured and Implied
1 like136 views
The document discusses technical debt, emphasizing its impact on agile development and the importance of code quality assessment metrics such as complexity, coupling, and testability. It highlights the significance of managing and prioritizing technical debt to prevent functional and technical defects, which can arise from ignored quality metrics and poor requirements. Strategies for controlling technical debt include making it visible, enhancing coding practices, and integrating non-functional requirements with functional requirements to improve system architecture.
Technical Debt: Measured and Implied
- 1. Technical Debt Measured & Implied Omar Bashir Preventing technical debt is what allows development to be agile in the long run. Dan Radigan, Atlassian Design Testing Code Documentation Defects https://www.linkedin.com/in/obprofile/ @OmarBashir_40 obashir@yahoo.com
- 2. Code Quality Assessment ● Complexity – Cycolmatic complexity – Cognitive complexity ● Rule Violations – Bugs – Code smells – Security issues
- 3. Code Quality Assessment ● Code size – Classes/methods ● Inheritance and Coupling – Efferent coupling (Ce) – Afferent coupling (Ca) – Instability index ● Dependencies Ce Ce + Ca
- 4. Testability ● Testability is a reflection on design. – SOLID code is unit testable. – Decoupled code exhibits testing agility. – Maintainable and supportable systems are end-to-end testable. ● The testing pentagon. ● Code coverage, – Best viewed in reference to quality and relevance of tests. – Can be promoted as a yardstick of design.
- 5. Unit Test Coverage ● Failures ● Line coverage ● Branch coverage ● Complexity Coverage ● Historical Trends
- 7. Code Coverage ● Running coverage agent with executables. ● Monitor code execution post build and deployment. – Usually with subsystem and end-to-end tests. ● Determine coverage gaps between unit and higher level tests. – Useful only if overlap between the two intended.
- 9. Defect Trends ● Doing the right thing and doing it right. – Functional defects, ● Misunderstood requirements. ● Incorrect requirements. ● Can be a consequence of existing technical debt and can add to it as well. – Technical defects, ● Ignored code quality metrics. ● Ignored or delayed NFRs (Non Functional Requirements). ● Use of antipatterns.
- 10. Tools
- 11. Accepting Technical Debt ● Tech debt economics – Interest rate: increases with development activity. – Paid back in hard ca$h. – Circular debt, poor requirements adding to tech debt. ● Can result in side-effects, – Observable via implied metrics ● Accept technical debt only if interest rate is sustainable. ● Prioritise technical debt resolution on interest rate.
- 12. Implied Metrics – Dev Lead Time ● Directly related to code quality. ● Increases with – Complexity, – Class/method sizes, – Coupling, – Dependencies
- 13. Implied Metrics - Estimates ● Widening gap between estimation and actuals. ● Related to increased dev lead time. ● Adds to project uncertainty.
- 14. Implied Metrics - Reliability ● Lowering MTBF (Mean Time Between Failure) – Higher failure frequency. ● Increasing MTTR (Mean Time To Repair) – Repair in IT support = Recover. – Higher tech debt can lead to lowering recoverability.
- 15. Controlling Tech Debt ● Making tech debt visible. – Raise corresponding tasks against known issues. – Include tech debt in project RAID logs. ● Risks, Assumptions, Issues, Dependencies. ● Appropriately prioritise tech debt. – Cost of delaying remediation. ● Schedule with functional delivery. – Remediation cheaper when functional change in proximity of the debt.
- 16. Controlling Tech Debt ● Institute coding practices that progressively improve on quality metrics. – Compensate estimates for debt reducing practices. ● Perform meaningful architecture, design and code reviews. – Smaller code reviews reduce cognitive overload.
- 17. Controlling Tech Debt ● Enhance Definition of Done and enforce it using quality gates. – Builds break if tech debts metrics below acceptable levels. ● Preferably integrated in the IDE. – CI/CD tools block build promotion if critical functional and non-functional tests fail at any stage. – Quality gates are adjusted as the project progresses, ● Preferably towards higher quality.
- 18. Controlling Tech Debt ● Combining NFRs (Non-Functional Requirements) with functional requirements. – NFRs and functional requirements define system architecture. ● Does not require a big up front design. ● NFRs point to relevant architectural styles that can be adopted and adapted. – Relegating NFRs leads to suboptimal architecture. ● Leads to architectural debt.
- 19. Controlling Tech Debt ● Resolving defects, – Prioritisation is a key challenge. ● Suffers from bias and opinion. – Resolution scheduling conflicts with on going development. – Focus on DevOps and test automation.
- 20. Technical debt is a very useful concept, but it raises the question of how do you measure it? Sadly technical debt isn't like financial debt, so it's not easy to tell how far you are in hock (although we seem to have had some trouble with measuring the financial kind recently). Martin Fowler, December 2008