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.

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.

8. Code Coverage
JVM
Application
Jacoco
JVM
Test Suite

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