If not tackled head on, early and often 'Technical Debt' will quickly pick up and slow delivery of new products and features down. But where do we start to tackle debt and avoid the product credit crunch? Clear choices can only be informed through common understanding, mutual agreement, rules, and appropriate automation and metrics. Presenting some experiences of how to view and manage debt to create product ecosystems that that thrive.

1. Beating the Product Credit Crunch
Tales from the Tech Debt front-line
1

2. Why does Debt matter?
2
Failure to address reduces the ability to add end-user value

3. Causes of Technical Debt
3
Failure to invest in maintenance causes decay
Application Debt – Failure to keep your code clean Infrastructure Debt – Failure to maintain environments

4. Causes of Technical Debt
4
Pushing beyond limits of original design will cause failure
Architecture Debt – Extending beyond design safety limits or continuing to extend when on fire

5. Causes of Technical Debt
5
Failure to invest in good tooling causes delays and extends outages
Ecosystem Debt – Tools & Process not maintained or fit for modern development

6. Whose Debt is it Anyway?
• Classic Silo’d Organisations think Debt is a Technical concern
• Software products that are not maintained properly, just like houses, over time
• Will become costly to support
• People will avoid them
• Will lose value
• The issues maybe Technical but it’s the value of the Product that’s affected
• Short term can be a strategic advantage - longer term becomes a tactical error
• Need to plan for Debt management – It's unavoidable
6
Technical Debt should be thought of as Product Debt

7. What Leads to Product Debt?
7
Poor prioritisation decisions due to lack of understanding
Organisational Issues
• Not a true partnership between Product Owner & Technical Lead
• Belief Technical Debt is a Technical issue not a product issue
• Lack shared ownership of code
Communication Issues
• Poor communication & awareness
• Information provided is not sufficient to make informed decisions
• Lack understanding of implications of decisions
Lack of Principled Development
• Lack of focus on Technical Excellence (Quality, Security, Performance)
• Commercial & Time based pressures lead to short cuts that reduce Quality
• Short term view

8. Collaborative Partnerships
Delivery / Domain / Feature Teams
• You Build It, Ship It, Own It
• Product Owners exist within the Team
• Triumvirate Partnership – Product Owner, Tech
Lead & Iteration Manager
• Joint decision making
• Product Owners own the code & tools as much as
engineers
Excellence
• Focus on Quality, Efficiency, Long term view
• Pair Programming – reduced knowledge gaps,
higher quality output
• Test Driven Development – evolve code quicker
8
Collaborative partnerships that agree on all aspects of delivery
SMEs
Principals
Test Automation
Security
Performance
Deployment
Cloud Automation
UX
Product Owner
Tech Lead
QA
Developers
UX
App Support
Product Owner
Tech Lead
QA
Developers
UX
App Support
Excellence Domain A Domain B

9. Know Your Ecosystem – The Software Factory
9
• Product Owners should be aware of what is required & the costs to create, maintain, deploy and operate a system
• Software Factory defines the processes, testing, tools, standards and rules to manage software
• Aims to ensure efficient delivery, the long term sustainment of product and maximise ROI
Creating a service is not simply writing code
Unit Tests
Functional Tests
User / System Tests
Exploratory
In Memory Tests
Static Analysis
Integration Tests
User/System Tests
Performance Tests
Security Tests
Compatibility Tests
Reliability Tests
Deployment Tests Logging
Monitoring
Synthetic Transactions
Event Analysis
Correlations
UX Research
Acceptance
Criteria
BDD Scenarios

10. If you Want more Business & Customer Value
• Strategic – Lean Value Tree, Business Goals / KPIs, ROI
• Products – Visitor Activity, Conversion, AB & MVT, Customer Value
Then you will also Care about Change Processes & Product Fitness
• Delivery – Agile, Lean, Efficiency, Responsiveness
• Operations – DevOps, Support, Hosting Costs
• Quality – Code, Functional, Security, Performance Metrics
Need to invest in Tooling to help create visibility
• SonarQube - Code Quality
• Custom tools & monitoring
Data Driven For Processes & Technology
10
Understand how delivery & quality metrics change over time

11. Minimise The Technical Burden
11
• Tech Radar Defines what technology is safe to use, coming to end of life, or must be removed
• Aims to simplify and standardise the technical estate and minimise burden
• Should be aware of Technology that is becoming End of Life
• Should be planning replacement or upgrades
Prioritise upgrades to keep lean & efficient

12. Prioritising Technical Improvements
• Technical backlogs create visibility of improvements required
• Prioritise using a weighted attribute method – Impact vs Investment
• Not only for Technical Backlogs!
• Whole Team Should collaborate on defining attributes & weights
• Whole Team need to prioritise maintaining technical estate & ecosystem
12
Continuously apply technical improvements to stay healthy

13. What Is The Minimum Requirement
• Cross Functional Requirements (CFRs) – implementation of standards to a specific level
• Standards – set the expectations on how to implement something
• Maturity Matrices – define level of implementation required, prevents unnecessary rework and avoids
gold plating
• Audit systems on standards and maturity levels by the CFR implemented
• Whole Team should collaborate and agree on level of standard to be applied
13
There is no such thing as a non-functional requirement
Maturity Level Description / Capabilities Suitability
Level 1 Event capture is non-existent, not granular, or not… Throw away code
Level 2 Limited awareness of whole platform health Proof of Concept /
Experiments
Level 3 - Target Delivery Teams have full access to their application General early
development
Level 4 Shared monitoring dashboards available to anyone
with a need to be informed of an app
High risk / value services
Standard Product A Product B
Logging Level 2 Level 3
Deployment Level 4 Level 3
Database Schema Mgt Level 2 Level 1
User Journey Testing Level 1 Level 2
Healthchecks Level 1 Level 3

14. Evolving Architecture
• Evolutionary Architecture – incremental change designed for evolvability
• Emergent Design – identifying patterns to simplify as a system is grown incrementally
• Micro-services – modular, domain specific, support improved delivery and experimentation
• We often make decisions at the last responsible moment on architecture, technology stacks, etc
• Micro-services make change is easier & cost to replace or retrofit is low
• Need to recognise discovering the need to re-architect or change technology is part of the design process
14
Change is natural part of evolving systems

15. What Are The Key Take Aways?
• Managing debt is not a choice it’s a responsibility
• Include the cost to maintain, deploy and operate products in your analysis
• If Product Owners own the value and then they should own the debt
• Collaborate & Partner effectively with Tech Leads
• Understand options for decisions and impacts
• Continuously monitor our metrics over time and where improvements are required
• Continuously manage debt
15
Don’t be scared by debt but do act