Please enable JavaScript.
Coggle requires JavaScript to display documents.
Exploring the Costs of Technical Debt Management, Administración de…
Exploring the Costs of Technical Debt Management
What is "Technical Debt"?
Definition
Coined by Cunningham in 1992.
Metaphor of "going into debt".
Can be considered as a particular software risk.
Two sides of technical debt:
A little debt can speed up software develoment in the short run.
But spending extra time on "not-quite-right code" is like paying interest on that debt.
Classification
McConnell defined two categories of technical debt:
Unintentional
Intentional debt.
Fowler extended this classification and created the technical debts quadrants. The quadrants are formed by two dimensions:
Deliberate/Inadvertent
Reckless/Prudent
This type of classification is helpful in finding the causes of technical debt.
Technical debts can also be classified from the perspective of the software lifecycle.
Technical Debt Identification
Software Quality Assessment Methods
Code smells
Software Maps
Extended segmented constraint networks (EACN)
Tools for visualizing architectural decay
Approaches to facilitated technical debt quatification
Measure the decrease in software productivity during the software development process.
Estimate the cost of fixing software quality issues to achieve an ideal quality level.
Measure the healthiness of the software architecture.
Propagation cost and dependency analysis to quantify software architecture healthiness
Quantify design flaws, an indicator of technical debt, using influence, granularity and severity.
Strategies for paying off technical debt
Try to determine the time point at which technical debt has to be paid.
Paying the highest interest debt items first.
Paying technical debt items according to their predicted defect and change proneness.
Approaches for technical debt decision
Formilize the technical debt concept and decision making. In this approach, technical debt is modeled using implementation cost, rework cost and future evolution path.
Proposed Approach
Technical Debt Item
The proposed framework centers on a "technical debt list".
The "technical debt list" contains technical debt "items".
Each technical debt "item" has a set of properties which define:
What the technical debt is.
Where it is located.
When it was detected.
Who is responsible.
Estimation of the principal and the interest.
Principal:
The cost of eliminating the debt or the effort required to complete a task that is considered being postponed.
Interest:
Composed of two parts
Interest probability:
The likelihood that an incurred debt item turns to a problem by making other work more expensive over a gievn period of time or a release.
Interest amount:
Represents the amount of extra work that may be needed in the future if this debt item remains.
A simple Management Framework
Help organize the activities and information needed to manage technical debt in practice.
Designed to allow incorporation of human judgement in all phases.
This can evlove by incorporating results, understanding, specific techniques, and emerging theories.
Technical Debt Management Process
Consist of three general activities
(Technical Debt List)
Technical Debt Identification
What is?
Construct the technical debt list.
Technical Debt Measurement
What is?
This goes after identifying technical debt.
Estimate the principal, interest amount and interest probability.
Technical Debt Monitoring
What is?
Monitor debt items and make decisions on when and what debt items should be paid or deferred.
The changes in technical debt must be reviewed and reflected in the technical debt list.
Application in Release Planning
Release planning is one of the scenarios in which the technical debt management approach can be applied to help software projects make optimal decisions.
Release Planning process
(1) Selected all Technical Debt items associated with component X.
(2) Re-evaluate hight/medium/low estimates for these items based on current context.
(3) Estimate numerically principal for all items with high interest probability and high interest amount.
(4) Compare cost (principal) with benefit (interest probability * interest amount) and ignore any item for which the benefit does not outweigh the cost.
(5) Add up principal for all remaining Technical Debt items related to component X.
Limitations
There are some assumptions that may not always hold in practice:
Each technical debt item is independent of other items.
All types of technical debt can be described as individual items.
It is possible to capture all effects of that technical debt in the concepts of principal an interest.
Case Study Methodology
Subject Project
The project consisted of a small database-driven web application for water vessel management.
Team:
1 project leader
1 technical leader
7 developers
Software application from a Brazilian software company that provides enterprise-level software develoment, consulting and training services.
Case Study Process
This involved a company contact, who was also part of the research team and was in charge of the translation (English-Portuguese), data collection, and communication between the project team and the research team.
Data Collection
Collected baseline data about the effort, cost, and productivity of the project view
interview
with the project leader.
The project team created the initial technical debt list.
Use of Rothman's classification as part of the technical debt training for the project team.
Defined following types:
Design debt
Testing debt
Documentation debt
Defect debt
Collected 6 categories of data:
Baseline data of the project.
Costs of using the technical debt management approach.
Changes in the technical debt list.
Desicions on when and what technical debt item should be paid off.
Benefits of using the technical debt management approach.
Problems and suggestions for the proposed technical debt management.
Data Analysis
The cost data gathered from the sprint planning meeting was compared with the project's baseline to determine the effect of the proposeed technical debt management approach on the project.
These qualitative data were coded according to a coding schema developed based on the research questions.
Results and Findings
Planning Process and Decision Factors
The project leader's top concern is on-time delivery.
Time and resource availabllity are crucial in deciding whether to delay or pay off the debt.
The item with high interest amount and high interest probability will be more likely to be chosen to be paid off.
A good opportunity to pay off a debt item is when it is in the backlog or in maintainance.
Benefits and Impacts
Impact:
Started to consider the impacts of not paying off a debt in a sprint.
Benefits:
Increased awareness of the problems that may be overlooked otherwise.
Open minded with the possible problems that can be presented.
Makes easy to understand the gravity of the problem, allowing a quick decision.
Costs of Technical Debt Management
The costs of managing technical debt came from several different activities.
The major cost came from analysis and evaluation work.
Analyzing and evaluating technical debt items was the most time-consuming work.
The identification of technical debt had high-cost work.
The average effort devoted to the planning phase of the sprint increased after applying the technical debt management.
Conclusion
Costs and Benefits of Explicit Technical Debt Management
Costs:
Analysis and evaluation took the top position, accounting for the majority of the total management cost.
Identification of new technical debt items also incurred high cost.
The cost may vary depending on the size of the project.
The overall cost of technical debt management is small compared to the release planning cost.
Benefits:
Increased awareness of the problems that are as important as those raised by the customer.
Problems can be identified and handled earlier.
Facilitates comparing differents technical debt items.
Limitations and Threats to Validity
The case selected is a relatively small and young software project.
The physical distance and language barrier.
There might be some subtle points that were lost in the translations.
Inaccuracy of technical debt estimation.
Future Work
Carry out case study with a bigger and more mature software project.
Conduct more retrospective studies.
Administración de Proyectos II
Lectura # 1 - Mapa Mental
Carmen María Mok Zheng