1. CS 577b Software Engineering II -- Introduction
23 April 2017
Technical Debt
CS 510 Software Engineering
Supannika Koolmanojwong
© USC Center for Software Engineering

2. Outline What is Technical Debt? Technical Debt Patterns
Technical Debt Calculation & Estimation
Technical Debt – Industrial perspective

3. Technical Debt Example
“Guys, we don’t have time to dot every I and cross every t on this release. Just get the code done. It doesn’t have to be perfect. We’ll fix it after we release.”
“We don't have time to reconcile these
two databases before our deadline, so
we'll write some glue code that keeps
them synchronized for now and
reconcile them after we ship.”
Ref: Steve McConnell – ICSE 2013

4. Total cost of ownership
a financial estimate whose purpose is to help consumers and enterprise managers determine direct and indirect costs of a product or system.
including the costs to research, develop, acquire, own, operate, maintain, and dispose of a system ‪

5. Total Cost of Software Ownership
‪newtecharticles.com

6. Potential total cost of ownership
Computer hardware and programs
Operation expenses
Long term expenses
HW and SW
Network
Server
Workstation
Installation & integration
Purchasing research
Warranties and licenses
License tracking - compliance
Migration expenses
Risks: susceptibility to vulnerabilities, availability of upgrades, patches and future licensing policies, etc.
Infrastructure
Electricity
Testing costs
Downtime, outage and failure expenses
Diminished performance
Security (including breaches, loss of reputation, recovery & prevention)
Backup and recovery process
Technology training
Audit
Insurance
IT personnel
Replacement
Future upgrade or scalability expenses
Decommissioning

7. Common causes of technical debt
Business pressures
Lack of process or understanding
Lack of building loosely coupled components (hard-coded)
Lack of documentation
Parallel Development
Delayed Refactoring

8. Single System Development Perspective
Choices driven by potential
Market share
Future opportunities
Technical debt
Cost of failure to provide needed capability

9. Technical Debt Code Debt Deficit programming Software Decay CodeSmell
Toxic Code
Technical Debt
Software Decay
coined by Ward Cunningham
Design Debt
Technical
Inflation

10. Ref: Zadia Codabux and Byron J. Williams
Ref: Zadia Codabux and Byron J. Williams. Managing Technical Debt: An Industrial Case Study

11. Technical Debt Observations “Agile Project Management”, Jim Highsmith, second edition

12. Types of Debt “Managing Software Debt: Building for Inevitable Change”, Chris Sterling
Technical Debt
These are activities that a team or team members choose not to do well now and will impede future development if left undone
Quality Debt
There is a diminishing ability to verify the functional and technical quality of software
Configuration Management Debt
Integration and release management becomes more risky, complex and error-prone
Design Debt
The cost of adding features is increasing toward the point where it is more than the cost of writing from scratch.
Platform Debt
The availability of people to work on software changes is becoming limited or cost-prohibitive.

13. Technical Debt
“is a measure of how untidy or out-of-date the development work area for a product is”
Not the deferred requirements

14. Technical Debt “I don’t know what happened, I just changed one line”
“We can’t upgrade, It will break”
“We can’t upgrade the code, we don’t have time”
“We can’t upgrade the code, no one understands it”
“Just put in the comment XXX, we will do it later”
“Just put in the TODO comment”

15. Technical Debt intentional technical debt unintentional technical debt
cost to taking short cuts
unintentional technical debt
making mistakes
Conscious decision to optimize for the “present” rather than the “future”
cost of not dealing with these short cuts and mistakes will increase over time. 
Read more: 

16. http://pkruchten. files. wordpress

17. http://pkruchten. files. wordpress

18. http://pkruchten. files. wordpress

19. http://pkruchten. files. wordpress

20. Outline What is Technical Debt? Technical Debt Patterns
Technical Debt Calculation & Estimation
Technical Debt tool – Industrial perspective

21. Technical Debt Architecture or the platform technology mistake
Scalability, reliability
Foundations are poorly design
you don’t find out until too late (operations phase)
no choice but to start again or rewrite big chunk to keep it working
Read more: 

22. Technical Debt Error-prone code
“ .. If I change X, it is going to break Y, I think ..”
“ Don’t touch that code, last time we did, we spent a week fixing it…”
20% of the code where 80% of bugs are found
Hard to understand
Dangerous to change because done poorly one in the first place
Not rewriting this code is one of the most expensive mistakes that developers make
Read more: 

23. Technical Debt Not easily tested
“ .. I thought we had a test for that ..”
Don’t have good automated tests
Tests keep falling apart when you change the code
Testing costs tend to go up over time as you write more code
Read more: 

24. Technical Debt Code that mysteriously works
nobody is sure how or why
Might be written by the geek who left the company
if nobody on the team understands it, it’s a time bomb
Read more: 

25. Technical Debt Others Forward and backward compatibility
Short term debt
Duplicate, copy-and-paste code
How many ? Trackable ?
Hard coding
Out of date documentation
“We just lost the drive, where are the backups”
If nobody is using it, get rid of it. If people are using it, why isn’t it up to date?
Read more: 

26. The Cost of Undetected Defects
Operation  Disposal
70%
85%
95%
Committed Costs
100%
100%
90%
Cost to Extract Defects
3X-6X
20X-100X
500X-1,000X
80%
70%
60%
Production/ Test
Cumulative Percentage of Life-Cycle Cost
50%
50%
40%
Requirements errors get progressively more expensive the longer it takes to find (and fix) them. As shown in this graphic, although the percentage of total life cycle costs is relatively low in the early phases of the project, the “committed costs” rise dramatically. We make early design decisions, vendor selections, architectures are nailed down and a whole host of other system constraints are defined very early in the life cycle. This means that undetected requirements errors will progressively require more and more re-work and re-design the longer it takes to find these errors.
30%
Development
20%
Design
20%
Concept
15%
10% 8% 0%
Time
Reference: Defense Systems Management College (DAU)

27. Development Cost(Perfect World)
% Effort per Phase
Analysis
Design
Implementation
Test
Integration

28. Classification of Defects
Analysis
Design
Implementation
Test
Integration
Defect Insertion
Defect detection & Removal
Defects
Typical Defect Profiles
Implementation
Defects

29. Development Cost(Real World)
% Effort per Phase
Analysis
Design
Implementation
Test
Integration

30. Development Cost % Effort per Phase Analysis Design Implementation
Test
Integration
Real world
Perfect World

31. Development Cost % Effort per Phase
Technical
Debt?
Technical
Debt?
% Effort per Phase
Technical
Debt?
Not enough information in this diagram to determine whether these are technical debt. The dip in the middle could represent technical debt from trying to move things along, but paying for it in integration and test.
Technical
Debt?
Analysis
Design
Implementation
Test
Integration
Real world
Perfect World

32. Development Cost % Effort per Phase Technical Debt? Technical Debt?
Analysis
Design
Implementation
Test
Integration
Real world
Perfect World

33. COTS Integration % Effort per Phase
This one shows that a decision must have been made that there was no real need to perform the System Definition activities. This represents Technical Debt.
Technical
Debt?
Analysis
Design
Implementation
Test
Integration
Real world
Perfect World

34. Fixing technical debt
80/20 rule
20% initial build
80% clean up

35. Outline What is Technical Debt? Technical Debt Patterns
Technical Debt Calculation & Estimation
Technical Debt – Industrial perspective

36. Financial debt vs Technical Debt
Interest payments
extra effort in future development because of the quick and dirty design choice
continue paying the interest
suffer for performance, problem is still there
pay down the principal
refactoring the quick and dirty design into the better design; also reduce interest payments in the future

37. Technical Debt Cost Estimation
Principal = Repair Effort
Interest = Maintenance Effort
[Nugroho et al 2011]
[Curtis et al 2012]
Debt
(in man days)
cost_to_fix_duplications +  cost_to_fix_violations +  cost_to_comment_public_API +  cost_to_fix_uncovered_complexity +  cost_to_bring_complexity_below_threshold +  cost_to_cut_cycles_at_package_level
Ref: Nugroho et al 2011, An Empirical Model of Technical Debt and Interest, MTD 2011
Ref: Curtis e al 2011, Estimating the Principal of an Application's Technical Debt. IEEE Software

38. No sample less than 10KSLOC
700 applications
158 organizations
357 MLOC
No sample less than 10KSLOC
Conservative - Assume all violations would be fixed within one hour
Weighted - varied the hours needed for fixing within each severity category,
More realistic -
based on data observed in several IT
organizations.
Ref: Curtis e al 2011, Estimating the Principal of an Application's Technical Debt. IEEE Software

39. Average Technical Debt per LOC = $3.61
Ref: Curtis e al 2011, Estimating the Principal of an Application's Technical Debt. IEEE Software

40. Ref: Curtis e al 2011, Estimating the Principal of an Application's Technical Debt. IEEE Software

41. Technical Debt within each technology

42. Outline What is Technical Debt? Technical Debt Patterns
Technical Debt Calculation & Estimation
Technical Debt – Industrial perspective

43. Sonar Mainly manage the software quality
SQALE – Software Quality Assessment based on Lifecycle Expectations

44. Nemo - An open source tool – by sonar http://nemo.sonarqube.org

45. Sonar – SQALE plug-in http://www. sonarsource

46. Developers’ 7 Deadly Sins
Bad Distribution of Complexity
Duplications
Lack of Unit Tests
No Coding Standards
Not Enough or Too Many Comments
Potential Bugs
Spaghetti Design

47. Developers’ 7 Deadly Sins
Bad Distribution of Complexity
Duplications

48. Developers’ 7 Deadly Sins
Lack of Unit Tests
No Coding Standards

49. Developers’ 7 Deadly Sins
Not Enough or Too Many Comments (time consuming maintenance)
Documented complex or not straightforward pieces of code
Readable unit tests scenarios that will help the developers understand the code
Documented API that will help external developers understand how to use those API
Respect of coding standard such as naming conventions
Potential Bugs

50. Developers’ 7 Deadly Sins
Spaghetti Design
Hunting for cycles
Checking your own architecture rules
Managing your libraries
Checking the single responsibility principle with LCOM4 (Lack of Cohesion of Methods)
RFC (Response for Class) – checking coupling (complexity of class in terms of method calls)

51. x = = x

52. Ref: Zadia Codabux and Byron J. Williams
Ref: Zadia Codabux and Byron J. Williams. Managing Technical Debt: An Industrial Case Study

53. Back up charts

54. Fixing technical debt Big Bang Dedicated Team Boy Scout
no new features for a year? Really? 
spend some time cleaning up the mess
Good ?
Dedicated Team
Have another team dedicated
Good ? 80/20 rule ?
Boy Scout
remove technical debt little and often
If no tests, add some. If poor test, improve them. If bad code, refactor it
The boy scout rule – leave the camp cleaner than you found it

55. Fixing technical debt Think time & risk & $$$ No gold-plating
Unnecessary task that no one wants
BigResearchUpFront vs BigDesignUpFront

56. Technical Debt vs Agile : Bad
Quick and dirty approach
Scalability vs DoTheSimplestThingThatCouldPossiblyWork
Just-in-time Scalability
change the architecture in response to actual customer demand
Wasted Code

57. Technical Debt vs Agile : Good
Get feedback faster
Smaller batches

58. Technical Debt vs Lean : Good
Less waste, less debt
Just-in-time nature

59. Technical Debt vs NDI : Bad
Product Development Leverage
Your product is fortified by others
Open-source, COTS, Services
Pros: Faster
Cons
Code understanding
Different coding styles, architecture, quality
No direct control