Towards a Technical Debt Management Framework based on Cost-Benefit Analysis

Towards a Technical Debt Management Framework based on Cost-Benefit Analysis (CoBeTDM)

M. Firdaus Harun and Horst Lichter

[email protected]

• Background• Idea• Example

Presented at The Tenth International Conference on Software Engineering Advances (ICSEA’15)Nov. 15 - 20, Barcelona, Spain

Technical Debt (TD) Scenario

[email protected] | CoBeTDM | ICSEA’152

Technical Business

Background - Technical Debt Metaphors


"Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite ... . The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. (1992)

A design or construction approach that is expedient in the short term, but that creates a technical context in which the same work will cost more to do later than it would cost to do now (including increased cost over time). (2011)

Ward Cunningham

Steve McConnell

Technical Debt Source

Design Debt

Architecture

Architecture Smells

Modularity Violations

Code

Code Smells

Code Violations



Why we need to reduce TD?

To avoid software ‘bankruptcy’

• Maintenance costincrease

• Productivity decrease

How to reduce it?

Maintenance/Refactoring

Strategy for TD Repayment – Cost-Benefit Analysis

Cost-Benefit Analysis (CBA)• To determine which maintenance/refactoring is valuable to be paid first (i.e.,

breakeven point) along the timeline of the project• Valuable – software is easier to maintain and less cost is needed in the

future

Why CBA?• Easy to understand by project manager (esp. technical people)• Can answer following questions:

Which maintenance/refactoring is cost-effective to incur or reduce debt? When the TD should be repaid? Now vs. next releases? How much should be repaid in each release to gain maximum benefit and minimizing

cost/risk? i.e., Return on Investment (ROI).


TD Meta Model

7

Example – TD Identification and Assessment: Debt Item

Field Description/Example

ID #DI001 | Package A

Critical Artifact (CA) Yes – 200 changes within 2 releasesImpact = 10 points

Code Smells (CS) God Class:WMC (41), TCC(0.66) and ATDF(11) = HighImpact = 7.5 points

Architecture Smells (AS) Cycle Dependency:Cyclic (3) = LowImpact = 2.5 points

Principal CA - Estimation effort = 8 man-hoursCS – Estimation effort = 7 man-hoursAS – Estimation effort = 5 man-hours

Interest Estimation extra effort to fix abovementioned Principal = 2 man-hours

Debt Sum Principal + Interest = 20 + 2 = 22 man-hours

Impact Points Sum CA + CS + AS = 10 + 7.5 + 2.5 = 20 points


Example – TD Prioritization at Release 1 (R1)

No.Debt Item ID

RefactoringImpact Points

(IP)Risk Points (R)

Total Cost (TC = IP + R)

Change Like. Points (CL)

Defect Like. Points (DL)

Raw Benefit Points (RB)

…

1 #DI001• Extract class• Cut dependency 20

• Regression bugs (2)• Testing (2) 24 7.5 7.5 2.5 …

2 #DI002• Extract method• Delegation 7

• Merge conflict (3)• Testing (2) 12 2.5 5 5 …

3 #DI003• Extract Method• Cut Dependency 11

• Build breaks (2)• Testing (2) 15 1 1 7.5 …

… … • … … • … … … … … …


…Debt Item ID

Total Benefit (TB = CL + DL + RB)

ROI (TB / TC) RankCost

(Debt Sum)Budget Left R1

(man-hours)Decision: When to Pay?

… #DI001 17.5 0.72 2 22 0 R1 (Now)

… #DI002 12.5 1.04 1 10 22 R1 (Now)

… #DI003 9.5 0.63 3 13 NA Next R2 (Delay)

… … … … … … … …

Open Questions for TD Monitoring


• How much TD do we have rightnow/current release?

• Is the TD at an acceptable level ornot? Does the TD continuouslygrows for each release?• What is an acceptable threshold

value of TD of each release?• What is a maximum TD (debt

ceiling) or minimum TD (debtbaseline) for each release?

• How to react when the TD reachesthe ceiling?

Current and Future Works

TD Identification• Validate a defined metrics, detection strategy and calculation model• Improve an estimation accuracy (e.g., inputs and outputs of Cost and Benefit analysis) from

historical data

TD Prioritization• Construct an explicit pre and post prioritization rule

TD Visualization • Develop a prototype tool

TD Management Process• Construct a process model i.e., based Software & System Process Engineering Metamodel

(SPEM)



Conclusion / Take Home Message

Cost-Benefit basedTechnical Debt Management

Towards a Technical Debt Management Framework based on Cost-Benefit Analysis

Software

Transcript of Towards a Technical Debt Management Framework based on Cost-Benefit Analysis